Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
Am 15.08.20 um 09:57 schrieb David C. Rankin: > ... > That is a shame. You just can't pull a videocard out of your i7 laptop to > update for fun, and you sure can't run desktop effects in KDE without it. I'm > not sure I understand the logic in Arch dropping the 390xx drivers relegating > a host of laptops Quadro cards to trying to build the nvidia-390xx, the utils > and settings package. Even following the list, I don't recall a discussion > about the discontinuation and there was no warning on update or error on > reinstall. > It was mentioned on arch-dev-public: https://lists.archlinux.org/pipermail/arch-dev-public/2020-March/029895.html There were no maintainers that were able to test the legacy nvidia packages anymore, so they had to be dropped. Unofficial binary packages are available in the disastrousaur[1] and jlk[2] repositories. The AUR package is mostly repackaging the upstream binaries anyways, only the kernel module is built from source. So I don't think it would be too bad to install it from the AUR. [1]: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#disastrousaur [2]: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#jlk -- ProgAndy
Re: [arch-general] Thunderbird 78
Am 15.08.20 um 05:39 schrieb Kusoneko: > On August 15, 2020 3:27:50 AM UTC, karx via arch-general > wrote: >> couldn't we package thunderbird 78 in >> the AUR for people who absolutely need 78, > > Sure, go ahead and do that if you want. > There is thunderbird-bin in the AUR which repackages the official upstream release of version 78.*
Re: [arch-general] pacman --assume-installed in a config file?
Am 18.06.20 um 16:26 schrieb Eli Schwartz via arch-general: > That seems a bit confusing :/ since it appears to only be used when > migrating away from a previously configured Oxygen selection. Does > anything else actually hardcode this? This dependency IMO should have > been a post_upgrade message or a noto-fonts replaces=() or something. > Noto Sans and Hack are set as the default fonts here: https://github.com/KDE/plasma-integration/blob/f30c8ca7c5c8576b8faf8e1d23cd57f403a9ffe0/src/platformtheme/kfontsettingsdata.cpp#L58 Those fonts are also explicitly listed as dependencies in CMakeLists, but that could be disabled as well: https://github.com/KDE/plasma-integration/blob/663d13e9fe9ea61d368bb5de73d1eea4cd9eb3e0/CMakeLists.txt#L53 -- Andy
Re: [arch-general] arch monthly brocken
Am 05.05.20 um 19:28 schrieb Zero via arch-general: > ... > Haven't had pacman updates for at least a month. > > I usually do once a week a pacman -Syu but no updates at all for at > least a month. > ... If you use a normal mirror and not the monthly archive the original question was about, then your mirror may have stopped updating for some reason or another. Choose another one. https://www.archlinux.org/mirrors/status/ https://wiki.archlinux.org/index.php/Mirrors#Sorting_mirrors
Re: [arch-general] post-install dependencies check
Am 21.02.20 um 21:52 schrieb Ralf Mardorf via arch-general: > ... > Btw. when installing it there was an issue: > ... > 2020/02/21 21:46:45 invalid character 'I' looking for beginning of value > error: command failed to execute correctly > ... > security.archlinux.org seems to be broken at the moment and returns "Internal Server Error". That is interesting.
Re: [arch-general] What happened to Arch Wiki recent changes news feed?
Am 15.11.19 um 10:01 schrieb Štěpán Němec via arch-general: > Thanks! I figured the wiki update must be related, but I haven't seen > that particular message. In any case, even though having the Special: > page require login might have made some sense, breaking the RSS feed > still seems like a bug, doesn't it? > You could maybe use the mediawiki feed api: https://www.mediawiki.org/wiki/API:Feedrecentchanges --- Andy
Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
Hello Amish, > I am not sure but I feel that install hook should now have higher > priority so that kernel is copied back to /boot as early as possible > instead of after most of the hooks. i.e. say after systemd hooks, may be > renamed to 40-mkinitcpio-install.hook? The order is correct. The initramfs should be created after depmod and the building of dkms modules. I don't see why the kernel should be copied earlier, anything that modifies boot entries should do it after the initramfs has been created. The order of hooks also has no impact on post-install scripts. Just don't use post-install to change the boot menu. At that time the initramfs images could still be missing even with the old packages that have the kernel in /boot. This would mess up the grub configuration as well. Regards, Andy
Re: [arch-general] Failed to compile dnsmasq latest git version with `-DHAVE_LUASCRIPT' on Manjaro.
Am 09.11.19 um 08:42 schrieb Ralf Mardorf via arch-general: ... > >>> Package lua5.2 was not found in the pkg-config search path. > ... > Regards, > Ralf > Hello, In this case the issue is a difference in packaging between debian and arch based distros. Debain provides lua5.2.pc as well as lua52.pc, while arch only has the latter. Lua itself does not provide any pkgconfig files, so those are added by the maintainers. If you use git packages, you should be able to detect such errors and create patches. $ pacman -Fl lua52 | grep pkgconfig lua52 usr/lib/pkgconfig/ lua52 usr/lib/pkgconfig/lua52.pc * https://packages.debian.org/bullseye/amd64/liblua5.2-dev/filelist /usr/lib/x86_64-linux-gnu/pkgconfig/lua-5.2-c++.pc /usr/lib/x86_64-linux-gnu/pkgconfig/lua-5.2.pc /usr/lib/x86_64-linux-gnu/pkgconfig/lua5.2-c++.pc /usr/lib/x86_64-linux-gnu/pkgconfig/lua5.2.pc /usr/lib/x86_64-linux-gnu/pkgconfig/lua52-c++.pc /usr/lib/x86_64-linux-gnu/pkgconfig/lua52.pc Regards, Andy
Re: [arch-general] Copy remote command server to clipboard
Am 26.08.19 um 13:47 schrieb Maykel Franco via arch-general: ... > Many thanks Ralph, it works, but... Is possible launch the command in my > server? > ... Hello Maykel, You can run a local server that copies everything it receives to the clipboard. Then set up ssh remote port forwarding and send clipboard data to this port. You need either netcat (nc) or socat as well as xsel, xclip or wl-clipboard. Server: $ socat TCP-LISTEN:6789,reuseaddr,fork EXEC:"/usr/bin/xsel -ib" SSH: $ ssh u...@example.com -R 6789:localhost:6789 Or set RemoteForward in your config. copy on server: $ uname -a | nc -c localhost 6789 or $ uname -a | socat -u - TCP:localhost:6789 https://gist.github.com/dergachev/8259104 -- Andy
Re: [arch-general] rkhunter found possible rootkit
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general: > On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote: >> I let rkhunter running around once a week. There were nothing since many >> months. But today it's report complains about */lib64/libkeyutils.so.1.9* >> and >> therefore other tools they're (seems to be) using this SO. >> ... > No, those libraries are used for key manipulation, that's why rkhunter > thinks that they might be sniffer. > In this particular case the filename was apparently used by a rootkit in 2013 and it was blacklisted. Now the legitimate owner of the libkeyutils filenames has reached the blacklisted version number. I don't know which of the two possibilities it is in your case. https://bugs.archlinux.org/task/63369 https://www.webhostingtalk.com/showthread.php?t=1235797
Re: [arch-general] pango 1:1.44-1 Renders Bitmap Fonts as Boxes.
> >>> You can convert your BDF/PCF fonts to the "X11 bitmap only sfnt >>> (otb)" OpenType format[1], which harfbuzz does support[2]. >> >> So these aren't "my" fonts. I'm using one of the bitmapped fonts that >> ships with X in xorg-fonts-misc as my terminal font. > > `My' bitmap fonts are also packaged. Hi Ralph, With 'your' bitmap fonts I also meant fonts you use, not only those you created or maintain. Doing the conversion yourself is only meant as a workaround if you really need them now, but you could offer the converted fonts in the AUR and become a maintainer if upstream is not interested. > There doesn't seem much point packaging a font in a format that isn't > supported by most software. The xorg-fonts packages are primarily meant for applications using XLFD (can only use bitmap fonts) or Xft (FreeType based, so bitmap fonts still work). > It would seem the upstreams, GNU and X.Org, should ship those fonts > in the current and OpenType-bitmap formats That would be for the best. > > Speaking of conversion, ProgAndy mentioned an Adobe program. The Adobe program is not useful for bitmap fonts, but the conversion of postscript/type1 (.pfa, .pfb) fonts to the opentype format. I mentioned it for completeness, since support for that format has been dropped as well. > > And FontForge should be able to do it > https://fontforge.github.io/generate.html lists ‘X11 bitmap only sfnt > (otb)’ amongst the bitmap types. > I found the scripts used to convert terminus to a mixed bitmap/vector font using fontforge, mkbold-mkitalic, and potrace. If you choose a font size that matches a bitmap height, then the resulting font will use the bitmap, otherwise the generated vector outlines [see *Notes*]. You could also try to declare your fontsize in pixel with a "px" suffix. This can be adapted to create a bitmap-only font in the "otb" format as well if you remove the potrace stuff and change the output file format from ttf to otb. https://files.ax86.net/terminus-ttf/#mkttf https://github.com/Tblue/mkttf *Notes* about the relationship between font sizes and bitmap dimensions: Font size is measured in typographic points: 1pt = 1/72 in. In a standard 96 dpi environment, that would be ~1.3 px. A 9pt font would be 12px tall. A 12pt font would be 16px tall. With a HiDPI display this is not true anymore, and with mixed DPI you might have to make sure that your chosen size resolves to an available bitmap in either case. -- Andy
Re: [arch-general] pango 1:1.44-1 Renders Bitmap Fonts as Boxes.
Am 28.07.19 um 20:35 schrieb David Rosenstrauch: > On 7/28/19 7:49 AM, Ralph Corderoy wrote: >> Hi, >> >> To save others' time, on upgrading to pango 1:1.44-1 today my terminal >> emulator and other programs displayed empty boxes instead of bitmap-font >> glyphs. This is due to deliberate dropping of support by Pango. >> https://gitlab.gnome.org/GNOME/pango/issues/386 >> >> I don't think xterm(1) uses Pango given ldd(1)'s output, and it's >> happily displaying nice crisp glyphs. > > Yeah, I just discovered this the hard way. Very annoying. Doesn't seem > like there's any fix/workaround either. > > DR Hello, You can convert your BDF/PCF fonts to the "X11 bitmap only sfnt (otb)" OpenType format[1], which harfbuzz does support[2]. As far as I know, there are no tools that do this easily. (There are a few old projects on github that might give a starting point like bdf2ttf). You can probably script fontforge, though. I think it should also be possible to put all different bitmap sizes and codepages in a single file, but that might require more manual work. Adobe Type1 (PostScript) fonts can be converted to OTF with the Adobe Font Development Kit for OpenType (AFDKO)[3] (The AUR package is out of date). This format should be readble by harfbuzz as well. [1]: https://fontforge.github.io/bitmaponlysfnt.html#X11 [2]: https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ "Note that Harfbuzz does support loading bitmap-only OpenType fonts." [3]: https://adobe-type-tools.github.io/afdko/AFDKO-Overview.html -- Andy
Re: [arch-general] Maria update
Am 28.06.19 um 11:49 schrieb Christian Hesse: > mick howe via arch-general on Fri, 2019/06/28 > 01:37: >> Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' >> in the MariaDB Servers datadir, errno: 13 > > What's the permission of /var/lib/mysql directory? I guess these were borked > before without being noticed. My systems have 0700 with mysql:mysql. > That is normal if you run mariadb-upgrade as an unprivileged user. It will work if you execute it as root or the mysql user. Your database has been upgraded successfully, but the logfile has not been written. You can ignore the error if you don't need the logfile.
Re: [arch-general] certbot automatic renewal: why twice a day?
Am 11.06.19 um 17:46 schrieb Łukasz Michalski: > Hi, > > Looking at timer example at [1]: > > "Add a timer to check for certificate renewal twice a day and include a > randomized delay so that ." > > Why try to renew twice a day? > Hi, This interval is recommended by the EFF here: https://certbot.eff.org/lets-encrypt/arch-nginx [...] running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason [...] -- Regards, Andy > I understand that there is 30 days before expiration date to renew. I > think weekly check should be enough for a server? > > Regards, > Łukasz > > [1] https://wiki.archlinux.org/index.php/Certbot#Automatic_renewal
Re: [arch-general] License for libdrm packages
Am 24.05.19 um 00:21 schrieb mar77i via arch-general: ... > > To answer my own question, of course I screwed it up already. > Okay, so license=('custom:MIT'), license=('MIT') or license=('custom')? > > manual says: put licenses from /usr/share/licenses/common into the license > array, otherwise use 'custom' / 'custom:LicenseName'. > > Depending on how many PKGBUILDs you've looked at in the past, you might think, > of course, you put license=('MIT') for MIT licensed projects in your PKGBUILD. > Which, as we now established, is incorrect, yet not actually enforced, and the > more important part of getting this right is to have the original license file > with the copyright notice in the package, as the document usually asks. > > I think we can bikeshed over the prefered 'custom' or 'custom:MIT' details > from > here on, however, a quick glance at my pacman database shows that a lot of > repo > packages actually don't do what the manpage say, of which there are asp, > wayland, sdl2... (the list goes on). > Those packages follow the exception published in the wiki[1] which allows license=('MIT') if you also include the exact license text with copyright notice in /usr/share/licenses/pkgname. This text has been there since the creation of the wiki page in November 2009[2] and I believe before that it was on another wiki page that has since been deleted without preserving its history[3], so I don't know where it came from. Should this really be declared as wrong now? Relevant paragraph of [1]: > The BSD, ISC, MIT, zlib/png and Python licenses are special > cases and could not be included in the licenses package. > For the sake of the license array, it is treated as a > common license (license=('BSD'), license=('ISC'), > license=('MIT'), license=('ZLIB') and license=('Python')), > but technically each one is a custom license, because each > one has its own copyright line. Any packages licensed under > these four should have its own unique license stored in > /usr/share/licenses/pkgname. > [1]: https://wiki.archlinux.org/index.php/PKGBUILD#license [2]: https://wiki.archlinux.org/index.php?title=PKGBUILD=85178=85175 [3]: https://wiki.archlinux.org/index.php?title=Building_Packages_in_Arch_Linux=history
Re: [arch-general] Any particular reason for daily imagemagick updates?
Am 06.03.19 um 02:25 schrieb David C. Rankin: > On 03/05/2019 05:39 PM, Joel Klinghed wrote: >> Well, the changelog (https://www.imagemagick.org/script/changelog.php) >> is fairly clear about the upstream release cycle: >> >> 2019-03-05 7.0.8-32 >> 2019-03-04 7.0.8-31 >> 2019-03-03 7.0.8-30 >> 2019-02-28 7.0.8-29 > > Yes, that seems to be more a side-effect of the ease of creating a release on > git rather than the historical deliberative process of what to include, patch > and the normal Q that takes place during the 'alpha', 'beta' stages before > we reach a 'release'. > > The changelog seems to reflect that Arch is NOT following the stable branch of > imagemagick. > > The latest release on the "Master" branch is: > > Release build (7.0.8-27) (released 24 days ago) > https://github.com/ImageMagick/ImageMagick/releases/tag/7.0.8-27 > > Why are we not tracking Master? > That just shows that ImageMagick doesn't care about keeping a proper git repository with tagged releases. Have you recently read the git log? Not even the commit messages are useful. Most commits have just three dots as the commit message or if you are lucky a bug tracker id.
Re: [arch-general] pacman.log has no timezone information in timestamp
Am 02.03.19 um 02:43 schrieb Juha Kankare via arch-general: > On 02/03/2019 02:23, ProgAndy wrote: > >> Am 02.03.19 um 01:12 schrieb mpan: >>>> I just used the /var/log/pacman.log for the first time to give me the >>>> last date-time I did a system upgrade ('starting full system upgrade' in >>>> the log). There is no time-zone info in the time-stamp. It's also not >>>> UTC. Does anyone know if this is by design or a bug? >>> `pacman` uses local time of your system. Indeed it seems like an >>> ommision. >>> >>> You may consider opening a feature request, so pacman.conf would allow >>> either an option to include TZ in the logs (good idea) or setting custom >>> time format (worse idea, as this would bind `pacman` codebase to the >>> specific time formatting function). >>> >> >> Meanwhile you can explicitly set the timezone to UTC when calling >> pacman, that way the log will be consistent: >> >> $ TZ=UTC sudo pacman ... >> >> -- >> ProgAndy > > For some reason, ' $ TZ=UTC sudo pacman' and '$ sudo TZ=UTC pacman' both > work, but '$ alias pacman="TZ=UTC pacman"' and then '$ sudo pacman' > doesn't, even though (from what I know) it should be practically equal > to '$ sudo TZ=UTC pacman'. Not sure why, but it was worth a shot. Any > other way to automate this TZ=UTC for pacman so you don't have to type > it every time. Maybe a wrapper script aliased to "upacman" or something? > Declaring an environment variable that way is a feature of some shells. It may not work in an alias, so you can use the env binary instead: alias pacman="env TZ=UTC pacman " A function should work as well pacman() { TZ=UTC /usr/bin/pacman "$@" }
Re: [arch-general] pacman.log has no timezone information in timestamp
Am 02.03.19 um 01:12 schrieb mpan: >> I just used the /var/log/pacman.log for the first time to give me the >> last date-time I did a system upgrade ('starting full system upgrade' in >> the log). There is no time-zone info in the time-stamp. It's also not >> UTC. Does anyone know if this is by design or a bug? > `pacman` uses local time of your system. Indeed it seems like an ommision. > > You may consider opening a feature request, so pacman.conf would allow > either an option to include TZ in the logs (good idea) or setting custom > time format (worse idea, as this would bind `pacman` codebase to the > specific time formatting function). > Meanwhile you can explicitly set the timezone to UTC when calling pacman, that way the log will be consistent: $ TZ=UTC sudo pacman ... -- ProgAndy
Re: [arch-general] BrlTTY Hard Dependency on eSpeak
Am 16.02.19 um 08:39 schrieb Daniel M. Capella via arch-general: > On February 16, 2019 2:32:43 AM EST, "Daniel M. Capella" > wrote: >> As mentioned earlier in this thread, upstream (espeakup, etc.) has to >> be engaged: >> https://lists.archlinux.org/pipermail/arch-general/2019-February/046055.html >> >> -- >> Best, >> polyzen > > Note that we could patch around this, but upstream support would be best. > > -- > Best, > polyzen > Hello, What is it that upstream should do? As far as I can see, brltty already supports dynamic loading of speech plugins. (see e.g. the --speech-driver paramter) The only problem seems to be that espeak-ng includes some compatibility files that conflict with the espeak package and prevent parallel installation. Wouldn't it be sufficient to split those two files into an espeak-ng-compat package? usr/bin/espeak usr/include/espeak/speak_lib.h -- progandy
Re: [arch-general] php-pear compromised
Am 23.01.19 um 22:08 schrieb Andy Pieters: > Any of you seen the news about php-pear? > > There's an AUR package that downloads from pear.php.net so if that was > within the last 6 months it could have been the compromised one? > > https://thehackernews.com/2019/01/php-pear-hacked.html > Please read the note in the aur comments. https://aur.archlinux.org/packages/php-pear/ Pierre commented on 2019-01-20 08:55 > Warning: The change in checksum was due to a security breach > at PEAR. The PEAR installer was tainted: > https://mobile.twitter.com/pear/status/1086634503731404800 > > You were affected if you installed php-pear 1:1.10.7-2
Re: [arch-general] MariaDB package version
Am 27.09.18 um 15:36 schrieb Genes Lists via arch-general: > On 9/27/18 7:04 AM, leoutat...@gmx.fr wrote: > >>> If you have further news, feel free to share. :) >>> >> Mariadb 10.2 and 10.3 are available in all distro except Arch >> https://downloads.mariadb.org/mariadb/repositories/#mirror=cnrs > > The link Eli provided references lots of client programs having problems > - but I didn't find a list of which client programs. > > Given how long this has been, I would like to suggest that the problem > lies with the clients at this juncture and not with mariadb. > > I see 3 basic options to choose from for each offending client package: > > (i) Drop client > (ii) Compile the client statically linked > ( removes the need to provide and older mariadb. ) > (iii) Provide 2 mariadb packages > Current and the older one needed for the clients to run using > shared libraries. > > > Hard to say without knowing which clients. And I don't know how much > work keeping both versions might be. This seems a bit similar to the > python situation where we still seem to have couplings to python 2. > > Does anyone have a list of the 'problematic clients' so a reasonable > decision can be made how to move forward and update mariadb? > > Eli how do you think we should proceed at this point? > > > thanks! > > gene Hello, I just looked at the sources for libmariadb (Connector/C) and it seems that there is an option to build it with compatibility symlinks for libmysqlclient: WITH_MYSQLCOMPAT. I am not sure which sonames are provided for compatibility, but according to mariadb.org the client library should always be binary compatible with the corresponding mysql release. Did anyone test if there are still incompatible clients with the most recent mariadb release? I have a fourth option if the symlinks cause problems. (iv) Ship mariadb with libmariadb only and provide an additional libmysqlclient package that contains a compiled copy of the real libmysqlclient. -- Andreas
Re: [arch-general] How to have multiple JDKs parallel?
Am 19.09.18 um 13:41 schrieb Olli: > On 19.09.18 10:41, Leandro Papi via arch-general wrote: >> The fact that Java 10 replaces Java 9 is a call made by Oracle, as >> described in their roadmap >> (https://www.oracle.com/technetwork/java/javase/eol-135779.html) >> [...]Java SE 9 was a non‑LTS release and immediately superseded by >> Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately >> superseded by Java SE 11[...] > What you describe here is not “Java” (which is a specification) and also > not OpenJDK but only Oracle JDK. It is a policy of the Oracle JDK > implementation but has nothing to do with Java itself. The OpenJDK > implementation of Java does not use anything like LTS, there will only > be the latest version which is a new one every six month (since > OpenJDK 9). > > Since the Oracle JDK is not in the official Arch Linux repos but only > the OpenJDK there is no need to talk about LTS on this mailing list at > all. > > Regards, > Olli There are LTS releases planned by AdoptOpenJDK, though. For now, Java 8 and Java 11 are declared as supported until at least 2022 [1]. These versions may be of interest for Arch Linux. Regards, Andreas [1]: https://adoptopenjdk.net/support.html
Re: [arch-general] How to have multiple JDKs parallel?
Am 18.09.18 um 00:23 schrieb Carsten Mattner via arch-general: > Hope you don't mind me hijacking the thread to ask if you've ever > extracted an adoptopenjdk tarball and were able to use it for running > a Swing GUI. The jdk10-openjdk (not bin, didn't try aur) package in arch > works, but whatever x86_64 tarball I download from adopopenjdk won't > display Swing GUIs. It just throws exceptions about font loading. > Do you have relevant experience to share/hint? There is a similar (the same?) error with MacOS builds: https://github.com/AdoptOpenJDK/openjdk-build/issues/489
Re: [arch-general] How to have multiple JDKs parallel?
Am 17.09.18 um 18:20 schrieb Guillaume ALAUX via arch-general: > On Mon, Sep 17, 2018 at 5:48 PM Carsten Mattner via arch-general > wrote: >> On 9/17/18, Eli Schwartz via arch-general wrote: >> >>> So essentially what you really want is a way for pacman to remember your >>> choice. That would require pacman modify its configuration which is >>> something that goes against the current architecture... What would happen >>> instead is pacman.conf could be used to configure this. >>> >>> I'm not sure if IgnorePkg or HoldPkg would have an effect here... >> The way I read it, what's being suggested is something like Debian's >> update-alternatives. https://wiki.debian.org/DebianAlternatives >> >> Or a JVM version manager ala pyenv etc. Not sure. > Just to give some backing: here is the official explanation of what > has already been stated before about JDK versions: > > "[…] non‑LTS releases are considered a cumulative set of > implementation enhancements of the most recent LTS release. Once a new > feature release is made available, any previous non‑LTS release will > be considered superseded. For example, Java SE 9 was a non‑LTS release > and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in > turn is immediately superseded by Java SE 11." [0] > > So keeping OpenJDK 9 in our repo while OpenJDK 10 is out would be the > same as keeping say OpenJDK 8.u181 while OpenJDK 8.u182 is out! Even > though I can understand the (developer) use case, this is clearly out > of Arch Linux' scope. > > [0] http://www.oracle.com/technetwork/java/javase/eol-135779.html > > Guillaume This might be a use case for remakepkg to remove the replaces-entry in the java10 packages. https://bbs.archlinux.org/viewtopic.php?pid=1771005 --- Andreas
Re: [arch-general] How to have multiple JDKs parallel?
Am 15.09.18 um 19:54 schrieb Olli: > LTS versions are only provided by Oracle for their JDK, not for the > OpenJDK. This graphic explains it quite well: > https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb There won't be any free LTS releases from Oracle, but the AdoptOpenJDK project wants to create public LTS releases every three versions beginning with Java 11. They also want to support Java 8 until 2022 > In addition, every three years one feature release will be designated as the > Long Term Supported (LTS) release. We will support LTS releases for at least > four years. This assurance will allow you to stay on a well-defined code stream, > and give you time to migrate to the next, new, stable, LTS release when it > becomes available. https://adoptopenjdk.net/support.html
Re: [arch-general] AppArmor support
Am 10.09.18 um 20:06 schrieb Levente Polyak via arch-general: > Sure, and thanks for doing so! Fair enough, at least if you are > bisecting/debugging... but then you are recompiling multiple times > anyway and nobody wants to and nothing stops you from keeping > CONFIG_PANIC_ON_OOPS off while doing so. > > However, that's not the average use case and that doesn't mean it must > be off for everyone, it will remain "better safe then sorry" by default > for the reasons i pointed out. > > cheers, > Levente > If the kernel boots, isn't it possible to use the sysctl "kernel.panic_on_oops" to disable the panic if it is really necessary? https://www.kernel.org/doc/Documentation/sysctl/kernel.txt --- Andy
Re: [arch-general] AUR: Failing to install gnupod-git (no perl-date-parse)
Am 07.09.18 um 17:38 schrieb Jeanette C. via arch-general: > ... > Hm, I'll have to go through the mailinglist then, since I can't search > AUR packages through the web interface. I get no search button in the > text-based browsers. :( > ... That seems to be no problem for me with w3m. Just enter the package name in "Package Search" and press enter. Or open the "Packages" link, enter your keywords in the search form and submit it with [Search]. The same works with the links browser as well. -- Andreas
Re: [arch-general] Can I build Arch Linux from Scratch?
Am 09.08.2018 um 09:53 schrieb Paul Gideon Dann via arch-general: On 8 August 2018 at 02:33, Turritopsis Dohrnii Teo En Ming < turritopsis.dohr...@teo-en-ming.com> wrote: Good morning from Singapore, Can I build Arch Linux from Scratch like Linux from Scratch? It's certainly possible to build all of ArchLinux's packages from source using the ABS. My approach would be to start on any Linux distribution by building Pacman, which will provide the makepkg script to allow you to start building Arch packages from source using PKGBUILD files. You'd want to start with the packages in the "base" group, followed by base-devel. You should be able to use Pacman to install each package file into a chroot, at which point your Arch system will be bootstrapped. But that's a lot of work. It's an interesting project, but I'm not sure there's much to be gained, practically, by building Arch like this as opposed to installing the pre-built packages. Paul There are a few dependency cycles that may have to be build in stages with bootstrap packages. First build package "one" without dependency on "two", then build "two" with dependency on "one", then rebuild "one", this time with dependency on "two". Maybe rebuild "two" as well. These bootstrap PKGBUILDs do not exist in the archlinux sources, so you have to create them on your own. Andreas
Re: [arch-general] xrandr with XPS 13" (3840x2160) HiDPI and 30" (2560x1600) LowDPI
Am 02.08.2018 um 10:10 schrieb Tyler: Small fonts on external screen with Qt5. xrandr --output eDP1 --scale 1x1 --mode 3840x2160 --pos 5120x0 \ --output DP1 --scale 2x2 --mode 2560x1600 --pos 0x0 --primary Small fonts on laptop using Qt5. So it seems tied to Primary switch as to which screen it scales for. Fortunately when using dual monitors I basically never use virtualbox, wireshark or nvim-qt on the laptop screen. Incidentally if no primary switch is used the eDP1 becomes primary. As far as I understand, QT_SCREEN_SCALE_FACTORS needs an entry for each screen. The primary screen will get the first factor, then second screen the second factor, so you can try this: QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS="2;2"
Re: [arch-general] xrandr with XPS 13" (3840x2160) HiDPI and 30" (2560x1600) LowDPI
Am 01.08.2018 um 04:20 schrieb Tyler: When I tried the reverse xrandr --output eDP1 --auto --output DP1 --auto --scale 2x2 --left-of eDP1 I didn't just get a flipped result, I got my browser showing over the middle https://i.imgur.com/QW0IHYw.jpg I guess --right-of/--left-of don't take the scale into account. Try to position your monitors absolutely with --pos, probably 0x0 for DP1 and 5120x0 for eDP1.
Re: [arch-general] xrandr with XPS 13" (3840x2160) HiDPI and 30" (2560x1600) LowDPI
Am 31.07.2018 um 05:17 schrieb Tyler: With the dual-monitor setup I'm struggling to understand the panning option. I have looked at https://wiki.archlinux.org/index.php/xrandr and the man file and still couldn't figure that track x track y part out. It's not very easy to understand. The panning option might be there as a workaround for a bug in xorg. Since xorg 1.20 the patch to resolve that should be included, so you can try your configuration without panning. https://wiki.archlinux.org/index.php/HiDPI#Side_display
Re: [arch-general] Arch Linux PC as a Remote Desktop Node
Am 27.07.2018 um 19:46 schrieb Foxtrot Mike via arch-general: On 07/27/2018 10:16 PM, Giancarlo Razzolini wrote: Em julho 27, 2018 14:07 Foxtrot Mike via arch-general escreveu: Here are the major tasks: 1- Ask LightDM to use Windows Domain (Kerberos) authentication. I am a little confused. There are supposedly many different ways with little changes to do this. [1] is one solution. LDAP is also a possibility. I need advice from someone who knows this field better than me :p 2- How to ask i3-wm (my default wm) to run freerdp at login? I guess [2] will get this done. 3- How to ask freerdp to authenticate using the ticket received from TGT during LightDM Domain authentication? If I could somehow configure freerdp to use Kerberos Tickets then the user won't have to enter his Domain password again. 4- How to ask i3-wm to close the X-session when freeRDP quits? I read something a while ago about .xsession files to achieve this functionality, but can't find it now. Hi Mike, You have some options here. I suggest you look into x2go and ltsp for starters. I don't suggest you use plain X over the network. With those 2 options you can have this kiosk mode you want, for the users to only be able to access windows. Regards, Giancarlo Razzolini Thanks for the reply. The issue with x2go and ltsp is that I'll have to separately manage username and passwords for local Linux login. The solution that I'd rather prefer would use Active directory authentication so the current system administrator won't have to do anything extra. The group policies are already there. Once the Arch system is properly configured, I'd disable local logins so there will be very limited chance for a user to corrupt/modify Arch system. And ideally, the user would have no way to interact with the local system. Thats why I want to limit the user to freeRDP. Anything else, and the X-session expires. Plus, I am very much into embedded linux systems (routers, SBCs, etc). I think putting the various pieces together would be give me a lot more to learn as compared to using a third party specialized software such as a kiosk script. Regards. The Arctica Project seems to be in the process of implementing exactly what you want. https://arctica-project.org/ https://github.com/ArcticaProject/remote-logon-service Regards, Andy
Re: [arch-general] nvidia-lts version
Am 05.06.2018 um 17:28 schrieb Doug Newgard via arch-general: On Tue, 5 Jun 2018 17:21:18 +0200 Hering wrote: Hello, is there a reason why the current nvidia-lts version is 396.24 but when checking https://www.nvidia.com/object/unix.html it says it should be 390.67? I am asking because the current nvidia-driver is causing problems with Unity here and I was hoping to fall back to the nvidia-lts package until things are fixed. But they seem to be the same version in the repo currently. Best, Marc It's nvidia for the -lts kernel, it has nothing to do with nvidia's lts releases. Hering, you probably want the package nvidia-390xx which is currently on version 390.59. 390.67 has been released only today, it might take a while to appear in the arch repository.
Re: [arch-general] Why no git --depth=1 option for makepkg?
Am 04.03.2018 um 01:08 schrieb Eli Schwartz via arch-general: Yep -- more or less this. There is no way for git to fetch "all commits since a given tag", and obviously `git describe` which is used in the standard pkgver() function cannot describe the remote repository... not to mention what happens when the repository has *no* tags, and git rev-list --count HEAD depends on all commits since the repository was initialized. Then there is the fact that --depth, or even --single-branch (not that this usually saves much space or time), will break on PKGBUILDs that use `git cherry-pick` to backport fixes (more commonly seen in non-VCS packages obviously). All in all, there is simply no way to generically support shallow clones in a generic way. The best you can do is take a given PKGBUILD, predict what it needs, and perform the clone manually according to handpicked criteria as makepkg will detect that clone and then simply fetch new changes which respects a previous shallow clone designation. Maybe a working option would be to implement fragmant variables for some git options like depth, shallow-exclude and shallow-since, but that is likely not trivial. source=("one::git+https://repo.git#branch=master:shallow-exclude=v4.14; "two::git+https://repo.git#branch=master:shallow-since=2017-12-30;) -- Andy
Re: [arch-general] Intel microcode - latest version not loading
Am 01.03.2018 um 00:41 schrieb Dutch Ingraham: On Wed, Feb 28, 2018 at 04:54:03PM -0600, Doug Newgard via arch-general wrote: On Wed, 28 Feb 2018 12:43:26 -0600 Dutch Ingrahamwrote: On Wed, Feb 28, 2018 at 11:50:09AM -0600, Doug Newgard via arch-general wrote: You're looking at the dates that the last *bundle* was released. That says nothing about what firmware is available for your processor. Your microcode was "updated early", so it is being loaded just fine. Scimmia Thanks, Scimmia. I had considered that, but thought that would have been spelled-out somewhere on Intel's site and didn't want to just assume. So, how does one determine what files are on the .img? The img file can be extracted with bsdtar. iucode_tool in the AUR used for working with the intel bin file inside of that .img file. It can list, extract, search, and more. There's even an example on the Microcode wiki page. Did you just add that wiki page information?? (I'm just kidding, of course.) Totally missed it - thanks for the info! In February Intel also released a PDF with available and planned microcode updates. The original now asks for a login, but this is a mirror: http://www-pc.uni-regensburg.de/systemsw/security/microcode-update-guidance_02122018.pdf Original location: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf
Re: [arch-general] dhcpcd-7.0.1-1 seems to break SLAAC
Am 23.02.2018 um 01:45 schrieb Jukka Salmi: With dhcpcd-6.11.5-1 starting this netctl profile results in an IPv4 address being configured via DHCP and an IPv6 address being configured via SLAAC as expected. With dhcpcd-7.0.1-1 starting this netctl profile results in an IPv4 address being configured via DHCP, but no IPv6 address is configured. ... Is anybody seeing the same issue? Is really dhcpcd to blame? TIA & cheers, Jukka Hello, that was a deliberate design decision, it is assumed that you will either want dhcpcd to handle ipv4 as well as ipv6 or you want to disable ipv6. https://roy.marples.name/archives/dhcpcd-discuss/0001903.html * ipv6: disable kernel RA if interface is active dhcpcd supports DHCPCv6 as well as SLAAC, but the "private" IPv6 is generated according to RFC 7217 instead of RFC 4941. That means you get a unique ipv6 for each network prefix that never changes. This article may explain it a bit better https://www.internetsociety.org/blog/2015/02/ipv6-security-myth-5-privacy-addresses-fix-everything/ More information about the reasons for the change here: https://roy.marples.name/archives/dhcpcd-discuss/0001907.html https://roy.marples.name/archives/dhcpcd-discuss/0001880.html It seems that there were too many complaints, so in git the behaviour has been changed again. (After the 7.0.1 release) https://roy.marples.name/archives/dhcpcd-discuss/0001942.html https://github.com/rsmarples/dhcpcd/commit/8f483d192082a953dd035f38ee4555735106f1fc /* * If dhcpcd is doing RS, disable RA support * in the kernel. Otherwise, leave it alone. * Logically it should be disabled regardless as dhcpcd can * do it better and the user saying no RS means no RS even the kernel, * but some crazy people want the kernel to do it still. */ Maybe in the future dhcpcd will have options for both ignoring ipv6 (letting the kernel handle it) and disabling ipv6. -- Andy
Re: [arch-general] How can I post on bbs.archlinux.org?
Am 30.09.2017 um 17:33 schrieb Merlin Büge: On Sat, 30 Sep 2017 11:07:53 -0400 Pierre Thibault via arch-generalwrote: So the solution would be for people to note the command on paper then to boot live (if their live version is working), run the command, note the result, boot back and go back to the registration page to put the result? If you have some basic experience with the linux command line, you don't actually have to run the command in a linux terminal. If you have no clue about it (yet), you might want to do some reading and get familiar with the linux shell basics before installing / using Archlinux, this might save you lots of trouble. There are many shell/bash emulators using javascript available in the internet. You could simply use one of them to run the command, and you can even use them to learn the basics of the linux shell. One example is "learnshell.org", you may find others with keywords like shell, bash, online, emulator, and/or javascript. Good luck, -- Andy
Re: [arch-general] makepkg - any way to recompile only newly patched files in large packages?
Am 07.08.2017 um 09:39 schrieb David C. Rankin: If it wasn't clear, I have already built the gtk2 package yesterday to --enable-debug=yes so I have all of the files in a state I could call --repackge on, except for the gtk/gtkrecentchooser.c file with the one line change. I was wondering if there was a way to avoid the full 15 minute rebuild of all of gtk2 and just compile gtkrecentchooserdefault.c to object and then --repackage? You can use makepkg with the -e (--noextract) option to rebuild from the existing source tree. If the configure step forces a full rebuild, you can comment it out in the PKGBUILD after the initial build. -- Andy
Re: [arch-general] Poor performance wifi BCM4331 - MacBookPro
Am 07.07.2017 um 21:34 schrieb Maykel Franco via arch-general: [...] I will try broadcom-wl because I see in this link: https://www.reddit.com/r/archlinux/comments/5qlyfm/cant_get_wifi_with_broadcom_bcm4331_chip/ Too I see broadcom-wl-dkms but I have the default kernel no dkms. Somebody with the same problem?? Hi, DKMS is not a kernel version, but a method to install kernel modules from source code https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support
Re: [arch-general] pavucontrol depency question
Am 20.03.2017 um 10:06 schrieb Christoph Gysin via arch-general: pavucontrol works fine without pulseaudio, if you control another machine's pulseaudio instance over the network: $ PULSE_SERVER=another-box pavucontrol Not sure about xfce4 packages, don't use them. Hi, You can use the pulseaudio client library to send audio to a pulseaudio server in your network. That works only for software using libpulse, though. It probably won't work for connections through pulseaudio-alsa. https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_over_network -- Andy
Re: [arch-general] hcidump is missing?
Am 09.03.2017 um 14:29 schrieb Peter Nabbefeld: Am 09.03.2017 um 13:38 schrieb ProgAndy: Am 08.03.2017 um 16:34 schrieb Guus Snijders via arch-general: It looks like hcidump is no longer supported: http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617 build: Hide deprecated tools under --enable-deprecated This marks the following tools as deprecated as they are not longer maintained or have been replaced by other tools: hciattach hciconfig hcitool hcidump rfcomm sdptool ciptool gatttool Though it is not very clear what can be used instead. I think the replacement for hcidump should be btmon (plus btsnoop?) For the rest I think it is like this: - hciattach seems to be replaced by btattach. - hciconfig can probably be replaced by btmgmt nad maybe bluetoothctl. - gatttool looks similar to btgatt-client. - hcitool seems to be replaced by the dbus device api without any commandline tool. - rfcomm and ciptool seems to be missing, they probably want you to use the dbus profile api. - sdptool seems to be missing, you should probably use the different dbus objects like the profile api, the advertising api, and the UUIDs list in device api and adapter api. -- A. Hello Andy, You seem to have a good knowledge about that - could You probably update wiki pages? Regards P. Hello Peter, What I wrote is about the extent of my knowledge. I'll add it to the wiki, though. I was looking for an rfcomm replacement, so I created a list of likely candidates for the deprecated tools. I never tried them and for the time being use rfcomm from the AUR: bluez-utils-compat -- A.
Re: [arch-general] hcidump is missing?
Am 08.03.2017 um 16:34 schrieb Guus Snijders via arch-general: It looks like hcidump is no longer supported: http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617 build: Hide deprecated tools under --enable-deprecated This marks the following tools as deprecated as they are not longer maintained or have been replaced by other tools: hciattach hciconfig hcitool hcidump rfcomm sdptool ciptool gatttool Though it is not very clear what can be used instead. I think the replacement for hcidump should be btmon (plus btsnoop?) For the rest I think it is like this: - hciattach seems to be replaced by btattach. - hciconfig can probably be replaced by btmgmt nad maybe bluetoothctl. - gatttool looks similar to btgatt-client. - hcitool seems to be replaced by the dbus device api without any commandline tool. - rfcomm and ciptool seems to be missing, they probably want you to use the dbus profile api. - sdptool seems to be missing, you should probably use the different dbus objects like the profile api, the advertising api, and the UUIDs list in device api and adapter api. -- A.
Re: [arch-general] How to "decorate" a package build?
Am 08.03.2017 um 12:20 schrieb Peter Nabbefeld: Thank You! However, while one part is about Firefox, the other is about changing builds while still getting the signalling for new builds from pacman. One possibility seems to use Hooks, while I'm not yet sure how to use them correctly. Regards P. Hooks don't work too well if you want to modify a package. Ralf has a good idea, I would change it a bit and do it like this: #!/bin/bash # 1) set pacman to ignore firefox upgrades # 2) perform normal pacman upgrade sudo pacman -Syu # 3) continue this script # pacman should still recognize that firefox is out of date even if the update is disabled if [ pacman -Qu firefox ]; then # download PKGBUILD from abs # patch PKGBUILD # build # install fi -- A.
Re: [arch-general] How to "decorate" a package build?
Am 08.03.2017 um 11:45 schrieb Peter Nabbefeld: Hello, is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)? E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package: Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update Kind regards P. Hello, That is impossible with pacman. What you can do is create a local repository that is included in the automatic pacman upgrade. Then write a shell script that checks for updates of the arch package, merges it with your local changes, build it and add it to the repository. You should change the package name with e.g. a prefix or suffix and add the original package as a conflict to make it work properly. Now your custom version is available for the next pacman upgrade. -- A.
Re: [arch-general] ofono install
Am 01.02.2017 um 23:06 schrieb Peter Nabbefeld: Hello, I tried to install ofono from AUR, because I want HSP/HFP support for pulseaudio (https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index35h3), but I get an error about a conflict between .SRCINFO and PKGBUILD - how can I resolve this problem? Kind regards Peter That sounds like you are using an AUR helper that compares the contents of the PKGBUILD to the .SRCINFO file that provides the display data for the AUR entry. The ofono maintainer only updated the PKGBUILD to 1.19 forgot to regenerate the SRCINFO (it still shows 1.18). In this case you should build the package manually using makepkg and at most a simple download helper like cower. -- Andreas
Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM
Am 27.01.2017 um 21:41 schrieb Eli Schwartz via arch-general: On 01/27/2017 01:27 PM, Christopher Reimer wrote: I also noticed a few other pull request trying exactly that, which were instantly closed by Kevin Mihelich without any reasonable explanation. That's why I expected some resistance and prepared myself to counterargument a few of his concerns. And I think I did quite good. Good enough to make him ignore me. Oh, he's ignoring you? I must be imagining this quote: I am speaking specifically to what is or will be officially supported. The community is free to do whatever it wants outside of official support, and many people do this already for a number of boards. Merely including the package here would imply official support to the vast majority of users despite any 72pt blinking red warnings we could put up state otherwise. This then leads to said users expecting us to fix their problems. This position is no different than it's been throughout the life of this project. Official support means an active, contributing developer has access to the hardware and can actively develop packages and address issues for that target. The hardware that we choose to spend our time and money on is our own choice, not a decision forced upon us. That seems to be a very reasonable position. If the patch is so simple, then why don't you maintain it and provide the necessary binary packages? You should be able to create a custom user repository for your modifications just like we do for Arch Linux for some kernels. -- Andreas
Re: [arch-general] Implement sql/sqlite database for pacman local database
Am 21.10.2016 um 21:48 schrieb Eli Schwartz via arch-general: The reason pacman uses a flat file database as opposed to a relational database, is the result of a deliberate design decision by the lead pacman developers. Therefore, I really really really doubt you will be able to convince them to change -- they already know all the arguments about speed, and declared that they preferentially value the current lack of complexity. Maybe a solution more in line with that would be to implement a search database similar to updatedb/locate.
Re: [arch-general] Package versioning
Am 02.09.2016 um 11:03 schrieb Magnus Therning: Yes, it looks like it would work better. Is there some description of what the presence of a letter actually means? /M The manpage for vercmp describes it with some examples: Version comparison operates as follows: Alphanumeric: 1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1 Numeric: 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0 Additionally, version strings can have an epoch value defined that will overrule any version comparison, unless the epoch values are equal. This is specified in an epoch:version-rel format. For example, 2:1.0-1 is always greater than 1:3.6-1. Keep in mind that the pkgrel is only compared if it is available on both versions given to this tool. For example, comparing 1.5-1 and 1.5 will yield 0; comparing 1.5-1 and 1.5-2 will yield < 0 as expected. This is mainly for supporting versioned dependencies that do not include the pkgrel. -- ProgAndy
Re: [arch-general] Kernel version in hooks
Am 17.05.2016 um 14:51 schrieb Damjan Georgievski: On 17 May 2016 at 14:50, Damjan Georgievskiwrote: Can I somehow get the kernel version from a hook invoked on the kernel package update? by version I mean the "4.5.4-1-ARCH" kernel version, not the "4.5.4-1" package version How do you detect the kernel package upgrade? If you use the path to its modules, you can add "NeedsTargets" to the hook and extract the version from the module path just like the dkms hook does it.
Re: [arch-general] Why isn't RetroArch in the Arch repos?
Am 01.05.2016 um 20:40 schrieb Diego Viola: Any reasons? Hi, There is no special reason, the arch maintainers simply don't have enough interest in this project. You can install it from the AUR, though. https://wiki.archlinux.org/index.php/Arch_User_Repository https://wiki.archlinux.org/index.php/RetroArch ProgAndy
Re: [arch-general] What is the current wiki-poliicy for re-writing contributions?
Am 23.03.2016 um 15:16 schrieb chaos Feng: On Monday 21 March 2016 12:22:30 David C. Rankin wrote: Archdevs, What is the current policy for having wiki-contributions re-written? I have been a wiki-contributor for years, I've more than 28 years Unix/Linux experience, I am an attorney, a registered professional engineer, and I have spent years doing technical writing for NASA MOD and Space Flight Operations -- I know technical writing. Over the past year or so it seems like every wiki contribution made is re-written to the point that the immediacy of the needed information is lost, is replaced by a link, or the contribution is reworded in a bewildering manner. Under what criteria does this take place? It has gotten to the point where you just get tired of helping -- why bother? Under the current system, the pages are slowly becoming less-useful rather than more useful as more and more information is chopped out of pages or replaced by links to 3rd-party pages that may (or may not) be there tomorrow. When I first began using Arch in '09, the pages were written such that you could fully-complete whatever task the page addressed without bouncing around from page-to-page hunting for all the pieces of the puzzle. That is no longer the case. Don't get me wrong, the Arch-wiki pages are still by far the most useful of any distribution, but understanding the criteria under which this is taking place will help those willing to contribute determine whether to make a contribution or not. The goal being to keep the Arch-wiki, the very best that it can be. Thanks. David, First, sorry to make you feel your work is undermined. There are two principles in my mind when doing Arch wiki admin work: "Remove duplication" & "Upstream first" 1. Remove duplication Duplication in wiki is just as bad as duplication in code. It is hard to maintain. When things change, usually only one location is updated and other places are left there out of date. When user see two sections document the same thing with different content, they will confuse. So some sections in "Beginner's Guide" is moved into their own pages. You could refer the talk page[1] to get the reson behind changes. Hello, Some time ago I stumbled on selective transclusions in the wikipedia help.[1] It seems to be an extension, that allows display of a partial article inside another article.[2] Maybe that would help to collect the necessary information in the "Beginner's Guide" [1] https://en.wikipedia.org/wiki/Wikipedia:SELTRANS [2] https://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion ProgAndy 2. Upstream first Arch wiki emphasize upstream just as Arch package emphasize upstream. It is great that Arch Wiki could be the document for every Linux topic. But it is even greater if Arch wiki could be the gateway of upstream document. If the document is not Arch specific, we hope it is contributed to upstream first and link back in Arch wiki. This way, it is not only benifical to Arch, but also to Linux/Free software as a whole. Thus we specify below policy: * If the upstream documentation for the subject of your article is well- written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information. [2] The best thing I like Arch: "Arch is a distribution that acts like just a distributor". Arch distribute packages which stay as close as upstream. We also hope Arch wiki could distribute our upstreams document to Arch user, not just duplicate the content here. It seems some contributors are disappoint about recent changes and I hope above explaination could make the change more logical. And for every change you do not like, please raise your concern in the Talk page[3]. Changes will be reverted if it is resonable. [1] https://wiki.archlinux.org/index.php/Talk:Beginners'_guide [2] https://wiki.archlinux.org/index.php/Help:Style#Hypertext_metaphor [3] https://wiki.archlinux.org/index.php/Help:Discussion Fengchao
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
Am 02.02.2016 um 10:40 schrieb Damjan Georgievski: https://github.com/andrewgregory/pachooks do hook files need to end in .hook ? I couldn't find it mentioned in man alpm-hooks or pacman Yes, a hook ends in .hook, that should be mentioned somewhere. I had to check the sourcecode: https://projects.archlinux.org/pacman.git/tree/lib/libalpm/hook.c#n620 Lines: 620, 667-671
Re: [arch-general] Mounting root according to fstab the first time (fstab in initrd)?
Am 20.01.2016 um 21:34 schrieb Garmine 42: First I will try to exclude root= and rootflags= parameters from the cmdline and include the fstab via mkinitcpio and see if it finds the root. Do I want to mask remount-fs in this case? That won't work. You'll have to create a hook for mkinitcpio that implements a custom mount_handler. In the install hook part, read the fstab data, write the necessary stuff to the image and add a runtime hook with add_runscript In the runtime hook, you change the mount_handler my_mount_handler() { mount ... } mount_handler="my_mount_handler"
Re: [arch-general] Firefox without signature checking
Am 02.01.2016 um 22:52 schrieb Kyle Terrien: It looks like that is only intended for release-status extensions. If I want to QA test a developer's beta build, this tells me that the developer would have to submit each build he wishes me to test to AMO. Why can't I just package the extension myself and load it? That is absurd. --Kyle Terrien The official stance is that developers and testers should use the "Developer Version"[1] of Firefox. That release does not require extension signatures. [2] Jan Steffens (heftig) provides us with a compiled Arch Linux package in his repository. [3][4] You can always provide or request an unofficial repository with binary packages of other firefox based projects. 1: https://www.mozilla.org/firefox/developer/ 2: https://wiki.mozilla.org/Add-ons/Extension_Signing 3: https://bbs.archlinux.org/viewtopic.php?id=117157 4: http://pkgbuild.com/~heftig/repo/ -- Andreas Bosch
Re: [arch-general] retext in aur is broken?
Am 07.10.2015 um 16:54 schrieb mudongliang: ImportError: No module named 'markups' But I found python-markups package installed in my system which provides this module. What's wrong with it? - mudongliang Hello, you'll have to recompile and reinstall python-markups. Python has been updated from 3.4 to 3.5 and the location for modules has changed. Rebuilding the package without changing the PKGBUILD (maybe increment the pkgrel) will fix it. ProgAndy
Re: [arch-general] What is the archlinux-bootstrap-2015.08.01?
Am 13.08.2015 um 09:54 schrieb David C. Rankin: All, In preparation for the motherboard change, I went to grab the latest netinstall-dual.iso and found the normal iso and then an 'archlinux-bootstrap' iso. Is the bootstrap iso the single architecture netinstall? I've checked the install, beginner's and download, but only found reference to the pxe boot which can't be that big? Hello, archlinux-bootstrap-$DATE-$ARCH.tar.gz contains a chroot environment to run pacman from any linux system. The process is described in the arch wiki.[1] It is not an iso image. https://wiki.archlinux.org/index.php/Install_from_existing_Linux#Using_the_chroot_environment -- ProgAndy
Re: [arch-general] LightDM GTK+ Greeter 2.0.0
Am 25.02.2015 um 16:33 schrieb Pablo Lezaeta Reyes: Hi all, Version 2.0.0 of the LightDM GTK greeter was released about week ago. This release drops GTK2 support. That's ironic, Xfce recommend lightdm as DM for the gtk2 theme, and the upcomimng xfce-gtk-engine 3.1 drop gtk3 support. gtk3 already dropped support for theme engines, so fixing the xfce gtk3 engine would be wasted effort.
Re: [arch-general] ncurses 5.9_20141101 no longer available
Am 15.11.2014 um 05:07 schrieb Savya: On Sat, Nov 15, 2014, at 01:05 PM, Ralf Mardorf wrote: On Sat, 15 Nov 2014 04:32:14 +0100 Karol Blazewicz karol.blazew...@gmail.com wrote: 5.9_20141101-1 This isn't the version from the official repositories. [rocketmouse@archlinux ~]$ pacman -Si ncurses Repository : core Name : ncurses Version: 5.9-6 [snip] Take a look what's enabled in your /etc/pacman.conf. I got the same message while updating, and I'm on the kernel.org mirror. The package was in testing, but it has been dropped a few days ago. Forwarded Message Subject:[arch-dev-public] Dropped ncurses from [testing] Date: Thu, 13 Nov 2014 21:08:31 +0100 From: Jan Alexander Steffens jan.steff...@gmail.com Reply To: Public mailing list for Arch Linux development arch-dev-pub...@archlinux.org To: Arch Linux Public Development List arch-dev-pub...@archlinux.org Hi, I dropped the ncurses prerelease version from [testing]. It had an annoying problem with tmux and the screen* terminfos that resulted in standout (reverse) being rendered as italic. Jan
Re: [arch-general] imagemagick 6.8.9.8-1 is slower than 6.8.9.7-1
Am 18.10.2014 um 08:22 schrieb Lukas Fleischer: After a more thorough analysis by Jan, we found out that the issue is caused by a bug in the new OpenCL benchmark code. On modern CPUs, the benchmark is executed on every start of ImageMagick which leads to huge number of __memcpy_avx_unaligned() calls with a small block size. Jan prepared a patch and he will submit it upstream. If you wish to use the current imagemagick version without a recompile you can set the opencl cache to a missing directory. Then imagemagick cannot write the cachefile and skips the benchmark. env MAGICK_OPENCL_CACHE_DIR=/tmp/CACHE_DOESNT_EXIST convert ...
Re: [arch-general] HD Videos
Am 09.10.2014 um 17:29 schrieb Heiko Becker: Removal of the HTML5 player fixed my problem. But just for curiosity, what plugins/ packages do I need for H.264 support? I will install the proprietary driver then soon (TM) ^^ Best, Heiko You'll need at least gst-libav and gst-plugins-good for h.264. MSE and MSE WebM VP9 can be enabled in about:config (media.mediasource.enabled) http://www.ghacks.net/2014/05/10/enable-media-source-extensions-firefox/
Re: [arch-general] java: cannot execute - too many levels of symbolic links
Am 09.09.2014 um 11:16 schrieb Thorsten Jolitz: I'm not active enough in the archlinux community to demand more efficient information politics, so I prefer leaving this to others. As a Emacs Gnus user I just think sometimes how nice it would be to subscribe to an 'archlinux.activities' group on gmane and keep being updated on all forum posts, all bug reports and maybe even all packages related actions by following that list from Gnus. It might be 3 different read-only gmane lists/groups too, for forum, bugs, packages, the important thing would be to not having to leave my newsreader to search in different (web)sites for current issues or problems. You can probably use gwene.org to read the rss feeds for these events. There are rss feeds for active forum topics, new bugs and package updates.
Re: [arch-general] [PATCH 1/1] systemd: restart services after update
Am 11.06.2014 19:23, schrieb Lukas Jirkovsky: On Wed, Jun 11, 2014 at 12:15 PM, Christian Hesse l...@eworm.de wrote: From: Christian Hesse m...@eworm.de --- [...] +for SERVICE in systemd-journald systemd-logind systemd-machined systemd-networkd systemd-resolved systemd-udevd; do + if systemctl is-active ${SERVICE} /dev/null; then +systemctl restart ${SERVICE} + fi +done [...] I don't like the idea of restarting _any_ daemons at all. It should be up to user to decide when a daemon is restarted. In my opinion restarting systemd-logind is a bad idea. What happens to an open session if the session manager restarts?
Re: [arch-general] My Apache Sever Compromised?
Am 09.04.2014 19:32, schrieb Jameson: On Tue, Apr 1, 2014 at 9:30 AM, Nowaker enwuk...@gmail.com wrote: 199.83.93.35 - - [29/Mar/2014:22:04:54 -0400] GET http://ro2.biz/pixel.png HTTP/1.0 200 151 But the most interesting part is that your apache is replying with 200, that is OK! Nice catch! It's certainly a proxy. Thanks for everyone's help with this. I did in fact have ProxyRequests set to On thinking it was needed for reverse proxies as well, and have turned it off. Now, when I open up port 80, it looks like they're still trying, but I'm replying with 404. Is that what it should be doing? I probably also need to make sure I have some throttling setup in case this is too much for my Internet connection. If you know the IP addresses (or address-ranges) you use to connect to your server, I suggest you block everything else for the time being with an iptables rule.
Re: [arch-general] pacman-key complaining, but what to do about it?
Am 02.04.2014 17:56, schrieb Magnus Therning: On Wed, Apr 02, 2014 at 10:16:04AM +0200, Magnus Therning wrote: On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning mag...@therning.org wrote: On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`: % sudo pacman -Syy error: haskell-testing: signature from ArchHaskell (Magnus Therning) mag...@therning.org is invalid :: Synchronising package databases... core108.2 KiB 1335K/s 00:00 [##] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##] 100% error: haskell-testing: signature from ArchHaskell (Magnus Therning) mag...@therning.org is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##] 100% community 2.1 MiB 1735K/s 00:01 [##] 100% multilib115.3 KiB 1746K/s 00:00 [##] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either. What else could it be? How do I find out? What can I do about it? I think I've found the reason for it: community.db: gzip compressed data, last modified: Wed Apr 2 04:23:21 2014, from Unix core.db:gzip compressed data, last modified: Tue Apr 1 19:08:44 2014, from Unix extra.db: gzip compressed data, last modified: Wed Apr 2 01:09:14 2014, from Unix haskell-testing.db: POSIX tar archive multilib.db:gzip compressed data, last modified: Wed Apr 2 05:12:37 2014, from Unix Where and why would un-gzipping strike like this? And now I've confirmed that this un-gzipping doesn't happen on my private computer at home. So, what's causing this un-gzipping of the downloaded repo db, I wonder? /M There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. The server sends these headers for haskell-core.db ( curl -I http://xsounds.org/~haskell/core/x86_64/haskell-core.db ) Content-Type: application/x-tar Content-Encoding: x-gzip It might work as expected without a Content-Encoding header: Content-Type: application/x-gzip
Re: [arch-general] pacman-key complaining, but what to do about it?
Am 02.04.2014 19:01, schrieb Daniel Micay: On 02/04/14 01:00 PM, Daniel Micay wrote: On 02/04/14 12:47 PM, Nowaker wrote: There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means. Packages are already signed, and pacman has support for signing the repositories. Using TLS for repositories is close to useless because the mirrors are not *really* trusted entities, and the CA system is a broken alternative to the solid archlinux-keyring package. We aren't actually signing the sync databases yet, but should be. Even if it means using a low-trust key on the servers, it would need to be treated differently than the package signing keys if it was a lower trust level though, because it shouldn't be able to sign packages. Maybe require all certificates used for package signing to have the codeSigning capability? The database certificate won't have that flag.
Re: [arch-general] Package conflicts
Am 25.03.2014 16:33, schrieb Doug Newgard: Date: Tue, 25 Mar 2014 10:03:59 -0400 From: jdarn...@buddydog.org To: arch-general@archlinux.org Subject: [arch-general] Package conflicts I'm having a problem with the liteide vs gocode-git packages. liteide, which is an official Pacman package, has recently started to include the /usr/bin/gocode binary, which I have been using via the AUR package gocode-git (there is also another AUR package called gocode-bin but no pacman package). So now when I try to update I get an error: error: failed to commit transaction (conflicting files) liteide: /usr/bin/gocode exists in filesystem This didn't seem to be right, as I'm trying to install liteide, not gocode here. So I reported the problem: https://bugs.archlinux.org/task/39607 and it immediately got closed with the statement that AUR packages aren't supported so contact the maintainer of the AUR package. Well, as far as I can tell, there isn't much the maintainer of the AUR package can do if some other package is going to just put any old binary wherever it wants without saying anything about it. Shouldn't the liteide package at least say it provides 'gocode'? Or conflicts or something besides just letting pacman complain about a file that exists in the filesystem? Carrying this a bit further, how would it or should it work if I did want to keep using gocode-git, but also use liteide? -- Jonathan Arnold Webstream: http://hieronymus.soup.io If you want to go fast, go alone. If you want to go far, you need a team ~ John Wooden As I said, contact the AUR maintainer. There are really two options; first, he can add liteide to the conflicts array, in which case you can't have them installed together. Second, he can move the conflicting binaries. Either way, it's something that needs to be done in the AUR package. Doug As far as I know, gocode is a go library (go package?). For python, each library is packaged separately, why is it different for go? Andreas
Re: [arch-general] Linux container
Am Mi 12 Feb 2014 18:44:11 CET schrieb arnaud gaboury: That means is that you need to make sure that the users on the host and the guest machine should have the same UID (usernumber) and GID(GroupNumber). The point is that you now have 2 computers that can access the same data. If you set access to certain files using different usernames, but identical (numeric) UID's, the wrong people could be able to access those files. Other then what one would think based on the displayed user- and groupnames. It would also make troubleshooting trickier. If you can keep the used numbers in sync between both installations, then every user/group permission means the same in both environments. mvg, Guus TY Guus for your answer. I think I understand the overall principle. The trick is I have no idea how setup all this stuff in a concrete manner. A basic example would help me. To secure your container you have to make sure that the users in the container will be represented as different ids to the host system. Especially root in the container must not have root access to the host. Here is some more reading material for you: http://libvirt.org/drvlxc.html#secureusers http://libvirt.org/formatdomain.html#elementsOSContainer
Re: [arch-general] arch rollback machine
Am Di 03 Dez 2013 10:36:16 CET schrieb archli...@jelmail.com: On 03/12/13 02:09, Gaetan Bisson wrote: [2013-12-02 23:55:29 +0100] Sébastien Luttringer: Ok, you want a fake db files with all versions of the same package. No, he just wants a directory with every version of each package in it. He won't ever update the db (no `pacman -Sy`) but can still install any package he needs with `pacman -S` using the outdated local db he has. If that's too big a directory to index, just drop an empty `index.xhtml` in it. People don't need to list its contents, they just need to know that they can have their pacman look for any version of any package there. Exactly spot-on - except that I will do `pacman -Sy`periodically but not necessarily before installing a new package. Also areed that indexing or browsing it is not a requirement. Many thanks to you. An easy way would be to let nginx rewrite urls from /arm/pool/X-pkgname to /arm/packages/X/X-pkgname. In the meantime this could also be achieved with a custom DLAGENT in pacman.
Re: [arch-general] [arch-dev-public] Dropping bluez4
Am Mi 06 Nov 2013 21:21:37 CET schrieb Andreas Radke: Blueman is broken and for many users not even starting. -Andy Hello, I thought about creating a GUI for gnome-bluetooth since bluetooth-wizard to pair new devices and bluetooth-sendto to send files should work without gnome, only gtk3 is required. The traymenu and pairing agent logic are implemented as a (private?) gobject introspection interface. We could simply latch on that interface. The rest is done in javascript for the gnome shell (not part of the gnome-bluetooth package). We can do that for other desktop environments with python. Andreas
Re: [arch-general] Revisit official SELinux support
Am Do 31 Okt 2013 11:29:32 CET schrieb Jelle van der Waa: On 10/31/13 at 09:36am, Allan McRae wrote: On 31/10/13 09:36, Timothée Ravier wrote: On 29/10/2013 01:21, Allan McRae wrote: I'd suggest that someone maintains an unofficial repo with all the packages required to set this up to prove the work required for continual maintenance of this has been done. Then requests could be made to (e.g.) add support to the kernel, providing full details of what is required and if it has any effect on those not using SELinux. Hi, I've had this on my TODO list for a while but never got to finish it up to the point of having a really functional system as it is quite time consuming (especially the SELinux policy fixing part). But I should have some time for it now so I'll try to make those packages. Impact for non-SELinux users should be rather minimal: * kernel: TOMOYO is already enabled and need explicit boot parameter to operate and so will SELinux once enabled. No major changes here except for a slightly bigger kernel. * userspace: only a very restricted set of packages needs tweaks, but it won't impact performance for non-SELinux users. No major changes here except for slightly bigger packages. Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support. Requiring patches not accepted upstream is an immediate blocker. I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful; I'm interested as a pacman developer what support would be needed, but that too is a likely blocker. * It needs a proper policy tuned for Arch Linux packages. Filesystem hierarchy differences between Fedora and Arch will prevent us from just applying the Fedora policy to Arch; * Performance comparisons between no-SELinux and disabled-SELinux installations to make sure the impact is minimal. Cheers, Tim Although I'm not a fan of SELinux, it would be nice if there was a list ( wiki article ) which lists all patches we need to apply on our packages. ( Who providers these patches btw. ) And which policy files we need to ship with our packages This wiki page already exists [1]. It mentions the patched packages are available in the AUR. I see no problem if someone wants to provide an unofficial binary repository for them. And as mentioned by Pablo Lezaeta, there exists a blogpost about arch with selinux [2] which is also referenced in the wiki. [1]: https://wiki.archlinux.org/index.php/SELinux [2]: http://www.jamesthebard.net/site/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/