- Arch-general - lists.archlinux.org

[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

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

26 Jul '16

On Sat, 2016-07-02 at 09:16 +1000, Allan McRae wrote: > > This sounds like the Fedora policy where packages have to surpass a > certain karma level to move into the main repositories. I'm not sure > who gets to vote for that though. > > A I would suggest allowing any Arch user vote yay or nay (with comments) - I believe this is what fedora did - only requirement was to be a registered user of the website. I don't imagine significantly more information will be obtained beyond the issues raised now in the mail list and forum. However, it does have the advantage of putting it in a single place for the packager. gene

3 2

[arch-general] New TeXLive 2016 packages in [testing]
by Rémy Oudompheng 24 Jul '16

24 Jul '16

Hello, I have published new TeXLive packages for the 2016 release in [testing]. The structure of the packages has been left unchanged (e.g. no introduction of pacman hooks). Feel free to test them and notify me of any problem or weirdness. Cheers, Rémy.

1 1

[arch-general] Discussion about optional dependencies from arch-dev-public
by Óscar García Amor 19 Jul '16

19 Jul '16

Hi. I write my two cents here cause I cannot post in arch-dev-public. The main problem of add "qt5-x11extras" as dependency is that it add a lot of more dependencies. Take note that virtualbox can run as server and, in this case, you not need to install the gui. You can run it in a machine without X. Maybe the solution is split it in two packages, virtualbox (for gui) an virtualbox-server. What you think? Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

3 3

[arch-general] [Classroom] Git for Gits
by fsckd 19 Jul '16

19 Jul '16

Hello, If you are interested in starting with Git, there will soon be a class for beginners called "Git for Gits", taught by polyzen and meskarune, on Saturday, 16th July, at 16:00 UTC. It will be held in the IRC channel #archlinux-classroom on the freenode network. The class will cover the basics of creating and using a Git repository. Git is used by many FOSS projects to manage code. It is used extensively in Arch Linux, such as on the AUR. You can also use it to track dotfiles, configuration, blog posts, college essays, and any textual data (and even non-textual). The class is also a workshop where you will get a chance to play around with a Git repository. Please visit the following web page to sign up. You will need to make an SSH key. Directions are on the page: https://wiki.archlinux.org/index.php/Classroom/git_2016 polyzen is a lactose intolerant Linux Professional. He has been using Linux for about 5 years, and switched to Arch Linux over 3 years ago. meskarune is an artist, programmer, and sysadmin. She has contributed to FOSS for 16 years and been an Arch user for 9 years.

1 1

[arch-general] Pacman doesn't optionally require fakeroot
by Bennett Piater 18 Jul '16

18 Jul '16

Hi, I have a quick question. Makepkg, which is provided by pacman, doesn't work without fakeroot. Is there a reason why pacman doesnt opdep on it? Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

3 3

[arch-general] recent archlinux installation
by Jude DaShiell 17 Jul '16

17 Jul '16

I'm using lynx but am pretty sure this problem will happen no matter which browser I use. The browser when connecting to https::// type sites throws an ssl error because it can't get local issuer certificates. I have SSL_FILE in /etc/lynx.cfg pointed at /etc/ssl/certs/ca-certs.crt and I ran c_rehash on the system with no errors yet this situation continues. Is a package and/or configuration needed so these ssl errors may disappear? I had done archlinux installations earlier and never had this problem then. --

5 5

[arch-general] texinfo, a dependency for libidn and libtasn1
by Damjan Georgievski 17 Jul '16

17 Jul '16

Do libidn and libtasn1 really require texinfo? makes texinfo uninstallable, but I don't need docs on this system. Does any of the "requiires" of texinfo[1] actualy require it? shouldn't it be an opt-depend? [1] https://www.archlinux.org/packages/core/x86_64/texinfo/ -- damjan

1 0