Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?

2020-08-15 Thread ProgAndy
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

2020-08-15 Thread ProgAndy
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?

2020-06-18 Thread ProgAndy
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

2020-05-05 Thread ProgAndy
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

2020-02-21 Thread ProgAndy
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?

2019-11-15 Thread ProgAndy
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

2019-11-14 Thread ProgAndy
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.

2019-11-09 Thread ProgAndy
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

2019-08-26 Thread ProgAndy
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

2019-08-20 Thread ProgAndy
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.

2019-07-29 Thread ProgAndy
> 
>>> 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.

2019-07-28 Thread ProgAndy
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

2019-06-28 Thread ProgAndy
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?

2019-06-11 Thread ProgAndy
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

2019-05-23 Thread ProgAndy
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?

2019-03-06 Thread ProgAndy
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

2019-03-02 Thread ProgAndy
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

2019-03-01 Thread ProgAndy
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

2019-02-16 Thread ProgAndy
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

2019-01-23 Thread ProgAndy
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

2018-09-27 Thread ProgAndy
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?

2018-09-19 Thread ProgAndy
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?

2018-09-17 Thread ProgAndy
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?

2018-09-17 Thread ProgAndy
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?

2018-09-15 Thread ProgAndy
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

2018-09-10 Thread ProgAndy
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)

2018-09-07 Thread ProgAndy
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?

2018-08-09 Thread ProgAndy

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

2018-08-02 Thread ProgAndy

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

2018-08-01 Thread ProgAndy

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

2018-07-31 Thread ProgAndy

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

2018-07-27 Thread ProgAndy

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

2018-06-05 Thread ProgAndy

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?

2018-03-04 Thread ProgAndy

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

2018-03-01 Thread ProgAndy

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 Ingraham  wrote:


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

2018-02-23 Thread ProgAndy

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?

2017-10-01 Thread ProgAndy

Am 30.09.2017 um 17:33 schrieb Merlin Büge:

On Sat, 30 Sep 2017 11:07:53 -0400
Pierre Thibault via arch-general  wrote:


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?

2017-08-07 Thread ProgAndy

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

2017-07-07 Thread ProgAndy

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

2017-03-20 Thread ProgAndy

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?

2017-03-09 Thread ProgAndy

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?

2017-03-09 Thread 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.


Re: [arch-general] How to "decorate" a package build?

2017-03-08 Thread ProgAndy

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?

2017-03-08 Thread ProgAndy

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

2017-02-01 Thread ProgAndy

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

2017-01-27 Thread ProgAndy

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

2016-10-21 Thread ProgAndy

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

2016-09-02 Thread ProgAndy

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

2016-05-17 Thread ProgAndy

Am 17.05.2016 um 14:51 schrieb Damjan Georgievski:

On 17 May 2016 at 14:50, Damjan Georgievski  wrote:

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?

2016-05-01 Thread ProgAndy

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?

2016-03-23 Thread ProgAndy

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?

2016-02-02 Thread ProgAndy

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)?

2016-01-20 Thread ProgAndy

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

2016-01-02 Thread ProgAndy

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?

2015-10-07 Thread ProgAndy

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?

2015-08-13 Thread ProgAndy

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

2015-02-25 Thread ProgAndy

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

2014-11-14 Thread ProgAndy

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

2014-10-18 Thread ProgAndy

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

2014-10-09 Thread ProgAndy

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

2014-09-09 Thread ProgAndy

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

2014-06-11 Thread ProgAndy

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?

2014-04-09 Thread ProgAndy

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?

2014-04-02 Thread ProgAndy

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?

2014-04-02 Thread ProgAndy

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

2014-03-25 Thread ProgAndy

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

2014-02-12 Thread ProgAndy

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

2013-12-03 Thread ProgAndy

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

2013-11-06 Thread ProgAndy

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

2013-10-31 Thread ProgAndy

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/