Re: [arch-general] rEFInd package being neglected by maintainer.

[Mike Cloaked via arch-general]

On Sun, Apr 12, 2020 at 6:01 PM David Runge  wrote:

> On 2020-04-07 12:54:18 (-0500), mike lojkovic via arch-general wrote:
> > rEFInd has had multiple versions came out, and the mainter has been
> > neglecting to update it for nearly two years. Is there an eta or talk
> > of changing the maintainer for that package? Pretty sure, it builds
> > find as an aur alternative has been up for awhile.
>
> Hi Mike,
>
> I've added refind to [testing] (replacing refind-efi). Feel free to
> check it out.
>
> Best,
> David
>
> --
> https://sleepmap.de
>

Fabulous - thank you.

-- 
mike c

Re: [arch-general] rEFInd package being neglected by maintainer.

[Mike Cloaked via arch-general]

On Tue, Apr 7, 2020 at 6:55 PM mike lojkovic via arch-general <
arch-general@archlinux.org> wrote:

> rEFInd has had multiple versions came out, and the mainter has been
> neglecting to update it for nearly two years. Is there an eta or talk of
> changing the maintainer for that package? Pretty sure, it builds find as an
> aur alternative has been up for awhile.
>

It does build with efi-libs easily in a few seconds on my laptop, but it
will need some work to build with tianocore. I have tried to build with
tianocore and the build fails but I haven't had time to look into what
changes are needed in the PKGBUILD file to make it work. That was just
using the PKGBUILD from the arch repo for the refind-efi package and using
the same additional files in the package file list. It would be nice to
know if there are issues that remain with the successful build that make
releasing the updated package undesirable.


-- 
mike c

Re: [arch-general] A few out of date packages

[Mike Cloaked via arch-general]

On Wed, Feb 12, 2020 at 6:46 PM Levente Polyak via arch-general <
arch-general@archlinux.org> wrote:

> On 2/12/20 12:58 AM, Genes Lists via arch-general wrote:
> > I've selected a few to highlight based on age and my own view of
> > importance (no claim its a good view).
> >
> > So, here's a few that might benefit from an update:
> >Cal Pkg
> > NameVers Updt   Flag   CVers   DateAge Age Pkger
> > ---  -- -- --- --  --- -
>

snip


> > elfutils0.177191118 191128 0.178   191126  85   8 EF
> > refind-efi  0.11.3   180723 181119 0.11.4  191112 568 112 TP [1]
> >
> > [1] 0.11.5 looks to be coming out soon
> >
> >   Cal Age = days since last update
> >   Pkg Age = days between current and arch release
> >   Cvers = Current version
> >
>
> Hi gene,
>
> thanks for taking time and trying to improve something in our distro,
> however I believe your numbers are, lets say: suboptimal
>
> snip
>


> Actually what does thunderbird even do on this list? I guess because its
> "Age" is 15? Which exactly proves my point above:
> Version 68.5.0, first offered to channel users on February 11, 2020
> which was exactly 1 day ago.
>
> On top this data set is inconsistent, thunderbird was released 200211
> and not as listed 200210 plus refind-efi was not released 191112 but
> 181112 and I didn't even check any other numbers besides those two.
>
> cheers,
> Levente
>
> https://sourceforge.net/projects/refind/files/0.11.4/
> https://www.thunderbird.net/en-US/thunderbird/68.5.0/releasenotes/
>
>
refind-efi has now been released and the source tarball can be obtained
from
http://sourceforge.net/projects/refind/files/0.11.5/refind-src-0.11.5.tar.gz/download

-- 
mike c

Re: [arch-general] Intel microcode - latest version not loading

[Mike Cloaked via arch-general]

>
>
>> That's excellent information.  Apparently, my 8 year old Core2 may soon be
>> getting its first MCU!
>>
>
>
>
My apologies for top posting - it was accidental.

There is a newer version of that file dated February 26th but I can't
remember where I downloaded it from.

I've put it at
https://filebin.net/q3s5in117kp7mkut/microcode-update-guidance.pdf if you
want to see it.

-- 
mike c

Re: [arch-general] Intel microcode - latest version not loading

[Mike Cloaked via arch-general]

There is a newer version of that file dated February 26th but I can't
remember where I downloaded it from.

On Thu, Mar 1, 2018 at 7:59 PM, Dutch Ingraham  wrote:

> On Thu, Mar 01, 2018 at 08:13:08PM +0100, ProgAndy wrote:
> > 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
>
> That's excellent information.  Apparently, my 8 year old Core2 may soon be
> getting its first MCU!
>



-- 
mike c

Re: [arch-general] ReadyDLNA/MiniDLNA doesn't work behind wireless

[Mike Cloaked via arch-general]

On Mon, Jun 5, 2017 at 4:12 PM, ITwrx.org  wrote:

>
> > ---
> > No idea why MiniDLNA does not check the port.
> i just installed minidlna and got it working from vlc over wireless. it
> didn't work at first. "systemctl status minindlna" showed that it wasn't
> able to identify the network interface i provided. i have no idea
> why(old method in minidlna?). i commented that line in config back out
> and made sure minidlna could read my testing media directory and it
> worked at that point. i used nmap -sS -sU -T4 -A -v 192.168.1.1 to see
> if port 8200 was open. it was.
>
> so, if "systemctl status minidlna" or "journalctl -b" shows no problems
> for minidlna then maybe test with nmap from both wired and wireless and
> see if there is a difference. If there is, then you have network config
> issue. the arch wiki page for minidlna has a section about wireless in
> the troubleshooting section i notice.
>

Although I don't run minidlna over the wireless interface on the server I
use, and only use the wired interface, I presume that the key here may be
as you suggest that the lines in /etc/minidlna.conf near the start of the
file that are relevant, which in my case are:

 # port for HTTP (descriptions, SOAP, media transfer) traffic
port=8200

# network interfaces to serve, comma delimited
#network_interface=eth0
network_interface=eth0

would need to include the correctly specified interface(s) for the server
running minidlna for the OP. I wonder what the latter line actually is for
that file in the problem machine?

-- 
mike c

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

[Mike Cloaked via arch-general]

On Wed, Mar 8, 2017 at 10:55 AM, ProgAndy  wrote:

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

You can also use the PKGBUILD to change the name of the package you build
and make your own version which you can customise or alter as you wish for
the build process. For example build it as package called say ff (pkgname=ff
) instead of firefox, and then run it in parallel to the official build. So
long users know to run ff instead of the stock version I can't see a
problem with that?


-- 
mike c

Re: [arch-general] About linux 4.8 and 4.9...

[Mike Cloaked via arch-general]

On Tue, Jan 10, 2017 at 1:53 PM, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:

> FYI, 4.8 has been EOL'd, leaving 4.4-lts, 4.1-lts as options for
> arch "default" kernel until 4.10 is released if we assume that
> there's a critical fix in the stable patch queue.
>
> My criticism of the stable patch queue is that they mix fixes
> with actual feature patches, making it more risky and not
> upholding a important fixes only policy.
>

Looks like there are some patches to try and are being tested for kernel
4.9 - see https://bugzilla.kernel.org/show_bug.cgi?id=191121

-- 
mike c

Re: [arch-general] New kernel repo

[Mike Cloaked via arch-general]

On Fri, Jan 6, 2017 at 7:36 PM, Simon Gomizelj via arch-general <
arch-general@archlinux.org> wrote:

> Check out https://wiki.archlinux.org/index.php/unofficial_user_reposit
> ories
>
> You may find a repository for the kernel you're looking for. Just be
> wary its obviously unofficial and thus unsupported.
>

It seems that the repo at http://arch.miffe.org/x86_64/ contains the
linux-mainline package which looks up to date.

-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 6:55 PM, SET <nm...@netcourrier.com> wrote:

> Le dimanche 4 décembre 2016 17:17:02 CET Mike Cloaked via arch-general a
> écrit
> :
> > The version current in arch is minidlna 1.1.6-1 but perhaps the comment
> > earlier in the thread about version 2.x is a heads-up for when the
> version
> > in arch is updated in the future at some point to make sure that 2.x does
> > support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
> > correctly.
>
> The 2.x comment above concerns VLC, and not minidlna. I'm using the same
> version as yours, on ALARM too.
>


Current vlc in arch is version vlc 2.2.4-5, and I have just double checked
that it works for UPnP - loading vlc in my desktop, and on the LAN, I can
immediately connect to my minidlna server running on a little odroid-c2
machine on the same network and can play video and see the other media
files on UPnP. So if there was any issue on an earlier version of 2.x it
doesn't seem to be an issue currently.

-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 4:19 PM, Peter Nabbefeld 
wrote:

> Hello Mike,
>
> I cannot find any important differences between Your files and mine. I've
> tested VLC, and if this is broken, the test doesn't have any relevance, so
> I need some other client first.
>
> Kind regards
> Peter


In my case I can run vlc from another machine within my LAN to see the
files on my media server running minidlna - one thing worth checking is
that you don't have any firewall blocks for the required ports on the
server. Again in my case the server is entirely within my home LAN and not
visible to the wider internet, so there are less security concerns in this
case than if the server was being accessed from the WAN.

The version current in arch is minidlna 1.1.6-1 but perhaps the comment
earlier in the thread about version 2.x is a heads-up for when the version
in arch is updated in the future at some point to make sure that 2.x does
support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
correctly.
-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 1:08 PM, Peter Nabbefeld 
wrote:

>
> Hello,
>
> I've installed minidlna (community/minidlna 1.1.6-1), but cannot access
> any files. When I access it on port 8200, statistics count some audio
> files, but those are videos (mp4). I also cannot see a list of the files
> (well, I even don't know, if this would be expected behaviour). If I try to
> connect via UPnP using VLC, I cannot even see any file.  Portscan detected
> port 8200 listening, but neither 80 nor 1900.
>
> So, I do have some questions:
> - Why are my mp4 files recognized as audio files?
> - Is minidlna expected t oshow a list of files in its DB somewhere?
> - How can I detect minidlna working correctly?
>
> It took me a while to get minidlna going (though I run it on an
archlinuxarm machine) -  and it is referred to with a different name in the
wiki:

https://wiki.archlinux.org/index.php/ReadyMedia

There are a number of things that have to be set right to make it work -
the permissions on directories including the home directory of the user
where the files are stored need to be set to allow the non-root user
running minidlna to access the files with the media.

eg in my case on my little media server:

$ ls -l /home
total 8
drwx-- 2 alarm alarm 4096 Feb 22  2016 alarm
drwxr-xr-x 6 mike  mike  4096 Jun  6 20:57 mike

then the minidlna.service file is:
$ cat /etc/systemd/system/minidlna.service
[Unit]
Description=minidlna server
After=network.target

[Service]
Type=simple
User=minidlna
Group=minidlna
ExecStart=/usr/bin/minidlnad -S
ProtectSystem=full
ProtectHome=read-only
PrivateDevices=on
NoNewPrivileges=on

[Install]
WantedBy=multi-user.target

and this service is started in my case with a systemd timer to avoid
startup timing issues on the small SoC on which this runs.

Then the minidlna conf file is:
$ cat /etc/minidlna.conf
# port for HTTP (descriptions, SOAP, media transfer) traffic
port=8200

# network interfaces to serve, comma delimited
#network_interface=eth0

network_interface=eth0



# specify the user account name or uid to run as

user=minidlna

#user=mike



# set this to the directory you want scanned.

# * if you want multiple directories, you can have multiple media_dir=
lines
# * if you want to restrict a media_dir to specific content types, you

#   can prepend the types, followed by a comma, to the directory:

#   + "A" for audio  (eg. media_dir=A,/home/jmaggard/Music)

#   + "V" for video  (eg. media_dir=V,/home/jmaggard/Videos)

#   + "P" for images (eg. media_dir=P,/home/jmaggard/Pictures)

#   + "PV" for pictures and video (eg.
media_dir=PV,/home/jmaggard/digital_camera)
#media_dir=/opt
media_dir=A,/home/mike/Music/
media_dir=P,/home/mike/Pictures/
media_dir=V,/home/mike/Videos/

# set this to merge all media_dir base contents into the root container
# note: the default is no
#merge_media_dirs=no

# set this if you want to customize the name that shows up on your clients
#friendly_name=My DLNA Server

friendly_name=Odroid Media Server

# set this if you would like to specify the directory where you want
MiniDLNA to store its database and album art cache
#db_dir=/var/cache/minidlna

db_dir=/var/cache/minidlna

# set this if you would like to specify the directory where you want
MiniDLNA to store its log file
#log_dir=/var/log

# set this to change the verbosity of the information that is logged
# each section can use a different level: off, fatal, error, warn, info, or
debug
#log_level=general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=warn

# this should be a list of file names to check for when searching for album
art
# note: names should be delimited with a forward slash ("/")
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

# set this to no to disable inotify monitoring to automatically discover
new files
# note: the default is yes
inotify=yes

# set this to yes to enable support for streaming .jpg and .mp3 files to a
TiVo supporting HMO
enable_tivo=no

# set this to strictly adhere to DLNA standards.
# * This will allow server-side downscaling of very large JPEG images,
#   which may hurt JPEG serving performance on (at least) Sony DLNA
products.
strict_dlna=no

# default presentation url is http address on port 80
#presentation_url=http://www.mylan/index.php

# notify interval in seconds. default is 895 seconds.
notify_interval=900

# serial and model number the daemon will report to clients
# in its XML description
serial=12345678
model_number=1

# specify the path to the MiniSSDPd socket
#minissdpdsocket=/var/run/minissdpd.sock

# use different container as root of the tree
# possible values:
#   + "." - use standard container (this is the default)
#   + "B" - "Browse Directory"
#   + "M" - "Music"
#   + "V" - "Video"
#   + "P" - "Pictures"
#   + Or, you can specify the ObjectID of your desired root container (eg.
1$F for 

[arch-general] Package updates for Long out of Date packages - comment

[Mike Cloaked via arch-general]

Not being able to post to arch dev public, and gaving seen that there was a
list posted by Florian Pritz today with sets of packages that have been
long out of date, I thought I would post a comment here about two
particular packages that appear in that list.

Having done some work privately recently on building refind-efi and
gnu-efi-libs, I wanted to note that refind-efi was recently updated in the
past few days, and is already at the latest version 0.10.4. I guess that
Florian will already be aware of that? Gnu-efi-libs is also on the list but
there is a very good reason that it has not been updated from version 3.0.3
to 3.0.4, which is that the newest version does not build for i686, at
least when I tried to do that in an x86_64 machine using abs, even though
it builds for x86_64, and that package is needed when building refind-efi
so that would probably need an upstream fix before it can be brought up to
date for both i686 as well as x86_64.

-- 
mike c

Re: [arch-general] Mirror issue

[Mike Cloaked via arch-general]

On Fri, Sep 16, 2016 at 8:20 PM, Jordyn Carattini via arch-general <
arch-general@archlinux.org> wrote:

> I keep getting http error 502 from the archlinux.polymorf.fr, I've been
> getting this error for the past month. Also sorry if I'm not posting this
> in the right place.
>

I have just made a connection to that mirror without any problem at all -
if you are still unable to connect then it may be a problem for a limited
set of users from specific routes to that site?

-- 
mike c