- Arch-general - lists.archlinux.org

[arch-general] rEFInd has been out of date for awhile.
by mike lojkovic 05 Aug '16

05 Aug '16

Hey everybody, refind-efi package in extra has been flagged out of date for about 6 months. The latest version is 0.10.3. There is refind-efi-bin <https://aur.archlinux.org/packages/refind-efi-bin/> in the aur. I'm just wondering if there are any plans to continue supporting rEFInd officially?

2 2

Re: [arch-general] links package hasn't been updated
by Alive 4ever 04 Aug '16

04 Aug '16

On Wed, Aug 03, 2016 at 02:57:40PM -0400, Jude DaShiell wrote: > Something to try as an experiment. In html options turn on number links > then run save html options and see if you manage to modify html.cfg file of > links. If that fails this bug was not fixed upstream. > There is no problem of using keyboard to access menu bar. The menu is working perfectly on my terminal (rxvt-unicode), except alt+s key, which is interpreted by urxvt as 'scrollback search'. For this key sequence, I just need to hit Esc+s to access links setup menu. On Wed, Aug 03, 2016 at 02:55:39PM -0400, Jude DaShiell wrote: > Can you adjust options in your new version? I use a screen reader and links > appeared in current version to be immune to keyboard input when configuring > options. In order to customize links I had to save configuration files then > edit them by hand. I didn't adjust any options in the PKGBUILD. Just modifying the source to fetch latest version and generating the correct SHA1 hash for the source tarball. I've tried setting 'links are numbered' html option and it persists after closing links. Just don't forget to hit 'save html options' after modifying html-related settings. Numbered links option is only available on the text only version (/usr/bin/links and /usr/bin/xlinks without -g option). The only thing to remember after modifying 'links' general settings and 'links' html options is to hit 'save options' to make the change persists. I hope this explanation will be useful.

2 2

[arch-general] efivars mounted read-write, but "operation not permitted, "
by Zachary Kline 04 Aug '16

04 Aug '16

Hi All, This is admittedly more about Linux in general than Arch specifically, but I’m wondering if anybody has insight into why I can’t delete EFI variables, when efivarfs is mounted read-write. For anybody interested, I am wanting to remove the default boot entry created by systemd-boot, but receive an “Operation not permitted,” message when trying to do so, even as root. Any insight would be appreciated. Thanks much, Zack.

5 5

[arch-general] links package hasn't been updated
by Alive 4ever 03 Aug '16

03 Aug '16

Greetings, developers. 'links' package has been flagged out of date for nearly one month and there is no updated package until now, not even in 'testing'. Is there anything blocking version 2.13 from being packaged? Firefox, which requires time and power to package has already available in 'testing' for less than two days. Compared to firefox, links doesn't need much power to package it. I am willing to create updated PKGBUILD if it's going to help maintaining this package.

2 2

[arch-general] Error Pacman
by Luciano Camerra 03 Aug '16

03 Aug '16

Can you help me with this error? Thanks. [root@li3 ~]# pacman -Syu :: Synchronizing package databases... core 118.6 KiB 488K/s 00:00 [######################] 100% extra 1765.6 KiB 907K/s 00:02 [######################] 100% community 3.5 MiB 532K/s 00:07 [######################] 100% :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: lib32-libglapi: installing mesa (12.0.1-5) breaks dependency 'libglapi

5 5

[arch-general] texlive-bin 2016.41290-2.1
by Genes Lists 03 Aug '16

03 Aug '16

There is a little noise on install Are these fixable - or benign? ---- (9/9) upgrading texlive- bin [################################] 100% >>> texlive: updating the filename database... recreating all formats...fmtutil [WARNING]: inifile aleph.ini for aleph/aleph not found. fmtutil [WARNING]: inifile lambda.ini for lamed/aleph not found. done.

3 3

Re: [arch-general] [arch-dev-public] libvpx moved to testing - dropping avidemux?
by nfnty 31 Jul '16

31 Jul '16

On 2016-07-31 10:19, Andreas Radke wrote: > The libvpx rebuilt packages have been moved to testing. Old avidemux > won't compile against it. A major update is pending for a long > time. Eric isn't around it seems already for a few months. > > Is there any Dev or TU wanting to take care of it? > > If not we should drop it to AUR. > > -Andy > I've tried contacting Eric multiple times regarding Avidemux. Opened a bug report [1] which got closed by Doug for apparently not being the proper place to report such things. Got an updated build over on github [2]. //nfnty [1] https://bugs.archlinux.org/task/48991 [2] https://github.com/nfnty/pkgbuilds/tree/master/avidemux/avidemux

1 0

[arch-general] community/go-tools godoc
by David N Murray 29 Jul '16

29 Jul '16

Greetings, I think I have two problems. The first is a simple packaging question. I have been using Go (community/go and go-tools, version 2:1.6.3-1 is currently installed and appears to be the latest package available) for a few years. Tonight I get this: $ godoc bash: godoc: command not found I usually start godoc for docs on the installed go packages I have in my project (godoc -http=:6060 &), so I know I used to have it, but it's been a few weeks since I tried to use it (2:1.6.3-1 was released 21-Jul and I upgraded shortly thereafter). $ locate godoc /usr/src/bin/godoc So, my initial question is what happened to godoc? I expected it in /usr/bin (same place that go, gofmt, etc. are installed). It seems to have disappeared: $ pacman -Ql go-tools | grep godoc $ pacman -Qo godoc error: failed to find 'godoc' in PATH: No such file or directory $ pacman -Ql -p /var/cache/pacman/pkg/go-tools-2:1.6.2-2-x86_64.pkg.tar.xz | grep godoc go-tools /usr/bin/godoc Did it get dropped, inadvertantly? I looked around the packages and it doesn't look like it got moved. My second question is regarding /usr/src/bin. I don't recall ever seeing that directory before and I don't have it on the other 2 arch boxen I built. Did I screw something up along the way? All the binaries in there are dated 25-Oct-2015. I'm using this godoc for the time being, but I can't tell which version it got packaged with (probably doesn't matter). TIA, Dave

2 1

Re: [arch-general] [arch-dev-public] signoffs are dead
by Kyle Terrien 26 Jul '16

26 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am replying to arch-general because arch-dev-public is closed to most users. On Tue, 28 Jun 2016 08:09:41 -1000 Gaetan Bisson <bisson(a)archlinux.org> wrote: > Dear all, > > For a while now packages in [testing] have gotten little to no > signoffs and I've been moving mine to [core] after a week without > feedback. I suspect many of you have been doing this too. Here's the > signoff reports over the last ten days: > > - June 19: 0 signoffs > - June 20: 6 from me, 4 from anthraxx > - June 21: 0 > - June 22: 5 from me > - June 23: 2 from demize > - June 24: 1 from me > - June 25: 0 > - June 26: 1 from me > - June 27: 3 from me, 1 from eworm > - June 28: 3 from heftig, 2 from arojas > > So I've decided to shorten the wait in [testing] to 48 hours. Many > updates to [core] packages include security fixes and they have better > move sooner rather than later. We used to be able to gather enough > signoffs to move these within a day or two, and that's what I intend > to do with or without signoffs. > > Any comment, and especially any other idea to fix this situation, is > welcome. > > Cheers. First, I am an Arch user (for 3 years now) not an Arch dev, and I realize I have no right to tell anyone how to run the distribution. What follows is just my personal recommendation based on working software QA professionally. With that said, I think eliminating signoffs is a bad idea. Signoffs ensure some form of quality control. A signoff is an explicit approval from someone that the package is satisfactory to his/her standards. A potential signee has a completely different perspective than the packager and a different way of verifying that the packager's package is correct. This sort of approval process catches errors that would otherwise escape the packager's notice. Simply waiting a period of time without hearing complaints is not equivalent to explicit approval from others. I have personally experienced several breakages in the past several months--more than usual. A few were big enough that simply running 'foo - --version' should have revealed a problem (i.e. linking problems). A signoff process would have very likely caught these problems. IMHO, the correct thing to do is remind other developers of the signoff policy. (And the above post to arch-dev-general certainly does just that.) Encouraging another set of eyes to look at someone's work and say, "This looks good to me," is a very good thing and does wonders in terms of quality control. If getting security fixes pushed out is a concern, then getting the security related fixes signed off should be prioritized. (Maybe by putting in a flag that automatically triggers a mail to arch-dev-public) Respectfully yours, - --Kyle Terrien -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXczI6AAoJEN5rMzXPJBsQASIP+gLGiQbQVrg/mNVDacXaHuEK 8H3QQz9amQMwgQXq8Mh17HWfbiQMQMWD48O9CBP+fUyWLVPOxs6g4H/aXFiIm4G+ Qw6/vWfgQaGjY60nLJ7D8/NVq9PwXSPEYF1cA8/6D7JtuotwXxCFENiNR9Qki7Un 3QCXRI6Z/KKGcpBvpIsa++qDeZuXnSTy00ZJO5EFYxTi+AUBEyffHX/bS2IUCOkC tUWxtoVIix4buD32/tCnPz19wku9MylddYBzNuB1qCD1NG6XLsxmn8WiHGeoiy+E uFwjxPgDx0MaldNNJzubC2LQD/osdTDTTPwDf2M0c802FI+pHxlj/Dk9imz86NFA 9xPH8WJ1cfiVTue0BkRJXlR2eI0VIPSqAbpcDCfzCwYbrFuFoqwszpET03PtF/Y4 5tfZHLODiFpDc9Whu5o4ejzf4p/eMUN3xmwUp+8cguFcSmjBSPvYvRbgI8puiPRm Al5xYxnrmghEf9R5fIRUWoHlsGNNMrmd1MKquJ6i1+Dkf0pmUK4t58G3crWjFb7+ laMUKYRmH+LwYhxvET562E8EM8QYYtow+PietZssC7ZhjGa1sG70FahQWCijmIj6 TdpfCiNgmQ8AF4C4JXhzZvONtdYzUeNSgiv/FkA9T4n9Xje/ZCUhyM+inaqmA/5A ComaWc2SjeM8gTBfdPQa =E42/ -----END PGP SIGNATURE-----

6 5

[arch-general] Removal of the Dasher package
by Germano Corrêa 26 Jul '16

26 Jul '16

Hello! I don't know if I'm in the right mailing list, so sorry if I'm in the wrong place... I need to install the package Dasher, and I realized it's not anymore in the official repositories (it was in extra and it was removed this year). I don't know if I didn't searched right, because I found nothing about this removal. Does anyone knows why? Of course I can download the source code and build it by myself, and that's what I'm doing. But I just wanted to know why they removed. Thanks, and sorry for anything...

4 4