Re: [arch-general] Mutt with Icloud
[2019-03-27 18:55:59 +0100] siefke_lis...@web.de: > have someone mutt with Icloud at work and can share the config? Your question has nothing to do with Arch Linux. You are far more likely to get a specific question on a particular piece of software answered by asking on the mailing list for that piece of software. In this case: http://www.mutt.org/mail-lists.html Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags
[2017-12-09 16:31:21 +] Jonathon Fernyhough: > Thanks for spending the time to consider the proposal and for your > valuable input, nevertheless. Your sarcasm is really pissing me off because I did take the time to review your bug report before replying with my analysis and two constructive suggestions for you. Let me recall them to you: Just write a `.toprc` to enforce your favorite options; problem solved. And if you really feel strongly about the new interface not matching your definition of "progress" you should bring your suggestions upstream. And what did you do with this "valuable input"? Conveniently ignored it so you could go on ranting and trying to rally people to your "cause". Guess what? That's not how change happens in open source circles, that's just a way to piss people off and make them ignore your future requests. So if you're serious about change start coding already and send pull requests upstream. -- Gaetan signature.asc Description: PGP signature
Re: [arch-general] [mpd+ncmpcpp] mpd hangs when manually moving forward on track, or to nex track
[2017-03-26 17:53:38 -1000] Gaetan Bisson: > [2017-03-26 20:22:58 -0600] Javier Vasquez via arch-general: > > If someone is familiar with mpd (user, non root) + ncmpcpp on Arch, > > perhaps can help me out... > > > > Whenever I move forward/backward on the same playing track (f/b), mpd > > just hangs, usually so hard, that mpd needs to be restarted to do > > anything. A workaround is to pause the track, and then move > > forward/backward, and then play again, most of the time that works... > > I can't reproduce this with ncmpc so it's probably ncmpcpp-specific. > Perhaps a rebuild against the new libmpdclient will fix this. But > anyhow, please create a bug report on our tracker. This is the proper > way to get things fixed. And to help us better understand your issue please tell us what specific versions of what packages are affected. Does downgrading ncmpccc, mpd, and/or libmpdclient fix the issue, etc. Cheers. -- Gaetan
Re: [arch-general] [mpd+ncmpcpp] mpd hangs when manually moving forward on track, or to nex track
[2017-03-26 20:22:58 -0600] Javier Vasquez via arch-general: > If someone is familiar with mpd (user, non root) + ncmpcpp on Arch, > perhaps can help me out... > > Whenever I move forward/backward on the same playing track (f/b), mpd > just hangs, usually so hard, that mpd needs to be restarted to do > anything. A workaround is to pause the track, and then move > forward/backward, and then play again, most of the time that works... I can't reproduce this with ncmpc so it's probably ncmpcpp-specific. Perhaps a rebuild against the new libmpdclient will fix this. But anyhow, please create a bug report on our tracker. This is the proper way to get things fixed. Cheers. -- Gaetan
Re: [arch-general] Mutt Compile-time Configuration
[2016-08-20 01:39:28 +0200] Bruno Pagani: > > > Le 20 août 2016 01:09:06 GMT+02:00, Dutch Ingraham a écrit : > >Hello all: > > > >Mutt 1.7.0 was just released.[1] One new feature is the sidebar, which > >up to now required a patched version of mutt from the AUR. However, it > >is a > >compile-time option and it appears as though the Arch packager has > >decided > >to not enable it (my muttrc will throw an error if I try and configure > >the sidebar.) > > I think that the packager just didn’t see this addition and only bounced the > pkgver. Almost: I saw the addition but assumed it'd be enabled by default. What's curious to me is that upstream chose not to enable a useful no-overhead option by default... Anyhow, I hope you'll be pleased with mutt-1.7.0-2. -- Gaetan
Re: [arch-general] about mrelendig's, scimmia's, and dreisner's behavior
[2016-08-11 00:28:37 -0400] Eli Schwartz via arch-general: > On 08/10/2016 11:39 PM, Gaetan Bisson wrote: > > I bet your momma told you not to swear and to start each sentence with a > > capital letter. So make her happy and start writing like a grown up... > > Well, perhaps Fnodeuser The Mysterious's mother also said not to use > disposable email addresses if one expects to be taken seriously. Good point. I've banned all addresses @mailinator.com from the list. If/when our friend switches to another disposable domain, I'll just add it too. Cheers. -- Gaetan
Re: [arch-general] about mrelendig's, scimmia's, and dreisner's behavior
[2016-08-11 04:08:46 +0200] fnodeuser: > these fuckers keep creating problems. > > they hided my tasks for the second time. this makes it impossible for the > package maintainers to see the tasks. > > i didn't come here to play games with archlinux team members who happen to be > fucking morons. i came here to contribute. > > it's time for them to be put in their place. they can't be reasoned with, and > we can't have a serious discussion about this anywhere else, because in the > IRC channels we have other stupid cunts jumping in always trying to derail > the discussion, namely, meskarune, keenerd, and polyzen. I bet your momma told you not to swear and to start each sentence with a capital letter. So make her happy and start writing like a grown up... -- Gaetan
Re: [arch-general] Why did kernel packaging become slow?
[2016-05-07 20:00:35 +] Abderrahman Najjar: > On Sat, May 7, 2016 at 6:24 PM, Tobias Powalowski via arch-general < > arch-general@archlinux.org> wrote: > > > Thanks Andy, yes this is correct. > > Sorry folks sometimes real life catches you and that's more important. > > I'm sure all understand this. > > I appreciate that. > But there are two maintainers listed on the package It takes time to carefully configure, build and test a quality package. I, for one, am perfectly happy with Tobias taking all the time he needs to make sure we can all depend on this critical piece of software. You are of course free to try and maintain a kernel package yourself, there are numerous options in the AUR too. -- Gaetan
Re: [arch-general] libreoffice not work
[2015-10-12 22:53:47 -0500] Yaro Kasear: > It seems like bad form to enable unstable features for a package in > [extra]. Shouldn't it be set to enable the GTK2 VCL by default? I'd normally agree but seeing as every line is commented out in our shipped libreoffice-fresh.sh it appears GTK3 VCL is an upstream default. Cheers. -- Gaetan
Re: [arch-general] postfix 3.0.0-3 in testing wont start
[2015-03-19 19:36:35 -0400] Genes Lists: > fatal: /usr/lib/postfix/postfix-script: No such file o $ /usr/lib/postfix/bin/postfix-script This script must be run by the postfix command. Do not run directly. -- Gaetan
Re: [arch-general] gnupg 2.1 not stable
[2014-12-17 09:03:31 -0500] Ido Rosen: > 2.0.26 is the stable version suggested for most users, > 2.1.1 is the brand-new modern version Arch is not stable, it's modern. Besides, there are no open bugs regarding gnupg on our tracker. -- Gaetan
Re: [arch-general] Meetup in Paris
[2014-08-29 18:29:25 -0600] José Javier Castro Matamoros: > Costa Rica? Please. Are we really going to whine for every neighborhood on earth? If you want an Arch meeting to take place in our area, make it happen, just like Sebastien is doing in Paris: find a room, speakers, sponsors for food/drink, etc. Nobody else is going to do that for you... -- Gaetan
Re: [arch-general] bugs.archlinux.org - enable comments on closed issues
[2014-08-25 04:27:51 +0200] Nowaker: > Closing an issue and preventing the reporter > from adding anything to the topic isn't respectful. Sorry but I am not following you: who owes respect to who? Disabling comments as issues are closed saves valuable developer time, not because of the occasional "thank you" but because comments on bug reports are prone to quickly degenerate into childish rants. > The same goes with moving the package from AUR to community without > letting the current customer know. There are no customers, but the users and maintainer should be told, yes. -- Gaetan
Re: [arch-general] [arch-dev-public] Rethinking our CA certificate setup
[2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
> - Ship the update-ca-certificates script in a ca-certificates-utils
> package, which the certificate packages depend on
> - ca-certificates becomes a metapackage depending on the -mozilla and
> -cacert packages
So we'd have three ca-certificates-* packages?
If this is this only to allow users to remove the bundles (mozilla or
cacert) they do not trust, then couldn't we instead just keep everything
in one package; simply putting the files
/etc/ca-certificates/conf.d/{mozilla,cacert}.conf
in the backup array would allow anyone to override them, so disabling a
bundle would also be super easy...
Other than the fragmentation of packages (my new pet gripe), your plan
sounds great!
Cheers.
--
Gaetan
Re: [arch-general] [arch-dev-public] systemd 215 group names
[2014-07-09 19:22:55 +0300] Martti Kühne: > I'm currently travelling and more or less only have this machine to > work with. Upgrading while travelling has never been the brightest idea. Couldn't you wait till you get back home for that? -- Gaetan
Re: [arch-general] inkscape doesn't start
[2014-06-23 19:07:25 +0200] Gerhard Kugler: > a few weeks I didn't start inkscape. Now it says: "inkscape: error > while loading shared libraries: libMagick++-6.Q16HDRI.so.3: cannot > open shared object file: No such file or directory" Update; it's fixed. -- Gaetan
Re: [arch-general] NTP: Possible permissions bug
[2014-05-09 08:26:59 -0700] Kyle Terrien: > In ntp-4.2.7, there is a file called .placeholder. I know, I put it there. :) Anyhow I'm glad you diagnosed your problem. -- Gaetan pgp2Z8jsm8yHj.pgp Description: PGP signature
Re: [arch-general] NTP: Possible permissions bug
[2014-05-08 18:34:54 -0700] Kyle Terrien: > I took out the "-u ntp:ntp" parameter (so ntp runs as root), and these > errors disappeared. Also, ntpq -p returns the NTP servers I'm > synchronized with. So, I'm pretty sure the issue is permissions related, > but I have no idea what it's running into. Any insight? What does `ls -la /var/lib/ntp/` say? Couldn't there be another daemon binding port 123? -- Gaetan pgp4ktYvhjNSN.pgp Description: PGP signature
Re: [arch-general] Move from libjpeg-turbo to mozjpeg
[2014-03-08 04:32:28 +0100] N30N: > https://aur.archlinux.org/packages/mozjpeg/ When you take the existing libjpeg-turbo PKGBUILD, change a few lines, and remove the Contributor/Maintainer tags altogether, you're not showing much respect for the community. > I'd like to propose making the switch. I'll happily discuss with anyone who has concrete arguments to offer. -- Gaetan
Re: [arch-general] FreeRDP
[2013-12-29 23:50:50 -0600] Ben Hagan: > There is a 1.1 stable branch in their repo, and it implements some changes > that make freerdp much better to use. Version 1.1 is a "pre-release" and the "latest release" is 1.0.2 as you can see there: https://github.com/FreeRDP/FreeRDP/releases Arch Linux sticks to stable releases whenever possible. -- Gaetan
Re: [arch-general] nut UPS driver (upsdrvctl) fails to start for usbhid devices due to node perms - howto fix?
[2013-12-16 21:33:33 -0600] David C. Rankin: > So if you think this should be in a new thread and not here -- talk to Gaetan. I'm quite confident no-one is going to care: it's now the third message you've send to this list about network-ups-tools. The first two haven't attracted much attention, so it's likely few people here care about that piece of software - nor should they, since it's unsupported. Obviously, we're happy to help with the occasional issue, but you have the annoying habit of sending every single one of your support requests to this list. So when you *really* have to post, please concentrate the noise in just one thread. > Is this a glibc issue or a nut issue? How about asking a network-ups-tools support list? Or its developers? This mailing list is for Arch-related discussions. This isn't one. -- Gaetan
Re: [arch-general] The Final Cleanup
[2013-12-06 18:15:36 +0100] Alexander Rødseth: > I think .desktop files should ideally be provided by upstream. But for > cases where they are not currently being provided, we should provide > them. Sure. That's exactly like service files, or rc.d files before that. Nothing new here. > Regardless of if it is correct that upstream should provide the > .desktop files or not, the current plan is not working. TUs and devs > are slow at reporting this as bugs and upstream are slow at > responding. At the current rate, this will take years, perhaps > decades. The current plan is not working. Why not? If a given package does not have a desktop file and nobody is bothered enough to write one up and submit it through our bug tracker, then that package does not really need a desktop file. > Here are the arguments for generating the .desktop files with a tool > like "gendesk": > > * There is much duplication of code by having one .desktop file per > (GUI) package > * If the .desktop specification should change in the future, there is > only one tool that has to be changed, not bazillions of little > .desktop files > * If there should be alternative ways of providing desktop shortcuts > in the future, possibly for other desktop environments, the transition > will be easier > * It's more elegant than including manually crafted files everywhere > * It provides one consistent look of .desktop files and avoids > problems (for instance, one hand crafted (or upstream provided?) > .desktop file used Terminal=1 instead of Terminal=true, which caused > problems). Generated files are consistent, which avoids problems. > * gendesk is already being used for several packages (and has been > used for a while), and it seems to work fine > * Many files are generating during the prepare or build process. > .desktop files should be generated too. So you suggest we use pacman hooks to deal with desktop files? Should service files be autogenerated as well? (I don't think so.) > If there are no protests, I will, after some time (say, three days > without any replies to this thread): > > * Create a TODO for this > * Start fixing the packages (I will not fix the packages of > maintainers that wish to reserve themselves from this, of course). I object to any mass automated update of our PKGBUILDs. Why are you making such a big deal out of such an insignificant issue? Packages for whom nobody has yet bothered to write a desktop file just have no need for one... -- Gaetan
Re: [arch-general] Patch for update-mime-info slowness
[2013-12-06 01:14:08 -0500] Sébastien Leblanc: > I was not > looking to file a bug, or anything. I am only sharing a patch with > fellow Arch users. Then why did you Cc the maintainer of this package? I'm not insisting that bug reports and feature requests be submitted to our tracker just to make it harder for you guys to report them. It's in everybody's interest to do so: this way maintainers can actually track them. For instance, if a dev loses interest in a package and another one picks it up, they have the full history of what has been fixed and what is left to fix. We wouldn't force people to use the tracker if that wasn't more convenient for us. And from a users' perspective, bugs reported on the tracker are more likely to get fixed... -- Gaetan
Re: [arch-general] Patch for update-mime-info slowness
[2013-12-04 15:00:31 -0500] Sébastien Leblanc: > I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: https://bugs.archlinux.org/ Not this list, not private emails to maintainers, not a combination of the above. This should really be clear to everyone by now... Starting now, I will reject any such emails submitted to this list and, if a whitelisted poster sends one, remove them from the whitelist. -- Gaetan
Re: [arch-general] New users not automatically added to 'users' group if -g default group specified?
[2013-12-04 22:12:40 -0600] David C. Rankin: > One question though, the USERGROUPS_ENAB flag seems self-explanatory, but > the > comments above the flag say: > > # > # Enable setting of the umask group bits to be the same as owner bits > # (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is > # the same as gid, and username is the same as the primary group name. > # > # This also enables userdel to remove user groups if no members exist. > # > > So, in addition to insuring umask group bits are the same as owner bits for > non-root users, this setting controls whether new users are automatically > added > to the 'users' group by default with useradd? See the man page to useradd: "If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB variable in /etc/login.defs. If this variable is set to yes (or -U/--user-group is specified on the command line), a group will be created for the user, with the same name as her loginname. If the variable is set to no (or -N/--no-user-group is specified on the command line), useradd will set the primary group of the new user to the value specified by the GROUP variable in /etc/default/useradd, or 100 by default." -- Gaetan pgpMb99USETA3.pgp Description: PGP signature
Re: [arch-general] New users not automatically added to 'users' group if -g default group specified?
[2013-12-04 12:57:23 -0600] Leonid Isaev: > On Wed, 04 Dec 2013 09:16:46 -0600 > "David C. Rankin" wrote: > > > In the past with arch installs, new users have always been added to the > > 'users' group. Now that is not being done. > > In short, this is OK; your user doesn't need to be mentioned in /etc/groups > after his primary group. If he is mentioned, then the primary group is also > his > supplementary one (which is anyway automatic). A while back, the default primary group for all new users was "users". It's not anymore: an individual group is created for each new user. One can disable USERGROUPS_ENAB in login.defs to get the old behavior. > This is done to save space in /etc/group on systems with large > number of users. So each user gets a home directory, generates log info under /var/log upon login/logout, /etc/passwd and /etc/shadow grow linearly in the number of users, but we are going to shave a few bytes off /etc/group? That's hard to believe. -- Gaetan pgpW71wwcQvss.pgp Description: PGP signature
Re: [arch-general] New users not automatically added to 'users' group if -g default group specified?
[2013-12-04 09:16:46 -0600] David C. Rankin: > In the past with arch installs, new users have always been added to the > 'users' group. Now that is not being done. Bug reports go to: https://bugs.archlinux.org/ Not this list, not private emails to maintainers, not a combination of the above. -- Gaetan
Re: [arch-general] [BUG]terminus-font
[2013-12-03 07:49:15 -0800] John Davis: > I wonder if this is why I have a problem with ncurses output in xterms.? Upgrade to xterm-299, it fixes a regression with line-drawing. If your bug is still not fixed then, file a bug report. -- Gaetan
Re: [arch-general] arch rollback machine
[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. -- Gaetan pgptkJv19r_nq.pgp Description: PGP signature
Re: [arch-general] Sorting by subject makes Evolution crash
[2013-11-29 18:20:57 +0100] Ralf Mardorf: > I'm a Linux user, not a Linux developer. I'm not asking you to develop anything. Just to report informative messages that your operating system makes readily available to you through a few simple commands. Obtaining a backtrace is a straightforward, well-documented process: https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#Getting_the_trace It's fine for a Linux user of ten years not to know how to do this, but it shows that they have little interest in getting things fixed... > I deleted the contend of the .xsession-errors files and tried to forced > a crash by sorting by subject, running Evolution in a terminal > emulation. You mean that you just typed "evolution" in an xterm? > _No_ crash, it took a very long time to sort by subject and Evolution > became unresponsive during sorting. Nothing was ad to .xsession-errors > and the only output after starting Evolution was: > > (evolution:9200): Gtk-WARNING **: Failed to register client: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.gnome.SessionManager was not provided by any .service files Now *that* is an actual piece of information. Although it seems unrelated to your sort-crash, thanks for reporting it... > It's not that easy to _use_ something and to troubleshoot. At the moment > I'm willing to disassemble my computer to troubleshoot a kernel issue. I > will do this, when I don't need the computer, but usually I need this > computer and the Evolution bug(s) appear from time to time, not when I > decide to troubleshoot. Your original message made it sound like Evolution crashes every single time you try to sort by subject. And now you say that the issue is not always reproducible? When you report an issue, you need to give all the information you have in the first email you send. Not just say "X crashes; help" and wait for someone else to extract details from you later on. -- Gaetan
Re: [arch-general] Sorting by subject makes Evolution crash
[2013-11-29 16:13:42 +0100] Ralf Mardorf: > Evolution crashes if I sort mails by subject. As usual, a backtrace would be nice... > I'm using Linux only for more then 10 years. Then you must know that discussing problems without giving the least bit of debugging information never goes very far. No, other people should not have to ask. It's up to you to describe all the details from your first message on. Next time you do this your post will be rejected. Cheers. -- Gaetan
Re: [arch-general] vsftpd build option --- why not support tcp_wrappers?
[2013-11-28 11:19:09 +0800] Yi Zheng: >Do you think it is necessary to add native tcp_wrappers support > for VSFTPD? No. See: https://www.archlinux.org/news/dropping-tcp_wrappers-support/ > I do not use xinetd, and want restrict FTP accessing > by IP. I would personally use iptables for that. You can write rules yourself or have other tools (mostly GUI) write them for you. See for instance: https://wiki.archlinux.org/index.php/Firewalls https://wiki.archlinux.org/index.php/Simple_Stateful_Firewall -- Gaetan
Re: [arch-general] Initramfs fallback render
[2013-11-15 01:55:12 +0100] Ismael Bouya: > when we need to boot into "fallback mode", initramfs asks for root > password! What is the exact prompt that seems to be asking for the root password? Wouldn't there be any helpful info/warning/error messages preceding it? That'd clear up some confusion around what part of initramfs (if any) is relevant here... -- Gaetan pgpGjb0U8N1IR.pgp Description: PGP signature
Re: [arch-general] Should outdated changelogs be removed from the packages?
[2013-11-12 22:25:32 +0100] Karol Blazewicz: > Should outdated changelogs be removed from the packages? Yes. No information is always better than inaccurate information. Unless the maintainers of those packages wishes to clearly mark their changelogs as outdated and keep them for historical purposes, they should be removed. -- Gaetan
Re: [arch-general] Sourcing /etc/rc.conf in configs and .install scripts
[2013-11-12 15:25:09 -0600] Leonid Isaev: > In the particular case of the filesystem package, I think the above > conditional is actually useful. It is never triggered on an initscripts-less > installation, yet it makes the filesystem package workable for people who > prefer legacy initscripts. The choice is between supporting an init system which we decided not to support anymore, and making the scripts from the filesystem package cleaner and easier to maintain. Easy choice for me... -- Gaetan pgpOM4FDr8WwD.pgp Description: PGP signature
Re: [arch-general] Sourcing /etc/rc.conf in configs and .install scripts
[2013-11-12 22:05:12 +0100] Karol Blazewicz: > I noticed a few configs and .install scripts mention /etc/rc.conf > (mostly it's just '. /etc/rc.conf'), even though initscripts are not > supported anymore. > > For example locale.sh from filesystem package has > > elif [ -r /etc/rc.conf ]; then > LANG=$(. /etc/rc.conf 2>/dev/null; echo "$LOCALE") > fi > > > Should I open a bug report for this? Yes. Opening bug reports never hurts. One per package, please. -- Gaetan
Re: [arch-general] linux-firmware upgrade altered grub
[2013-11-08 17:27:59 +] Anthony Campbell: > I see that what happened was a kernel upgrade. This > led to a lot of activity by mkinitcpio as it built the image. I don't > know if that could have altered the boot sector. No. What may alter the boot sector is a bootloader upgrade... -- Gaetan
Re: [arch-general] linux-firmware upgrade altered grub
[2013-11-06 08:56:04 +] Anthony Campbell: > After an upgrade yesterday which I'm pretty sure included linux-firmware > I found that boot reversed the order What do you mean by "pretty sure"? How do you know linux-firmware is to blame? This package only modifies files under /usr so it is unlikely that it affected your bootloader in any way. Perhaps if you gave us facts instead of mere speculation we could actually help... > and there were some other unwanted > effects too. Feel free to be specific. -- Gaetan
Re: [arch-general] Replacing journal completely with syslog-ng
[2013-10-27 18:41:36 +0200] Dimitris Zervas: > Journalctl requires too much resources (I have a 512MB KVM) and some times > it kicks the server out of memory. Unless you can refine your description of the problem, we can do nothing to help than give suggestions blindly at random. Here's one: add the sysctl parameter kernel.core_pattern=/dev/null Doesn't work? Tough luck; it worked for me... > there is nearly no way to parse its logs with any log analyzers What "log analyzers" are you referring to? -- Gaetan
Re: [arch-general] Static libs
[2013-10-26 09:39:21 +0200] Carsten Mattner: > So that means Arch Linux has always been unique in that regard > and it has been by lucky accidence static linking of libs installed > by pacman worked? Yes. > If that's the case this should be documented the same way other > distros (suckless) do not support dynamic linking of the provided > packages don't you think? It's obvious that static libs aren't supported by distros that ship none, don't you think? -- Gaetan
Re: [arch-general] Static libs
[2013-10-25 10:10:55 +0200] Carsten Mattner: > Is there still a way to statically link libraries where > the recent change to remove the .a files has been > completed? To build something statically you will just need to rebuild its dependencies statically too. Note that static libraries have never really been supported and were never shipped by most packages. The rebuilds we are doing are enforcing consistency rather than a new policy. -- Gaetan
Re: [arch-general] Fwd: Re: [arch-dev-public] Plasma-NM plasmoid moved to [extra]
[2013-10-12 22:44:44 -0400] Genes Lists: > I used it to connect to local wifi - worked fine. Left my laptop > and returned a couple hours later. I am still connected - and the hover > pop up shows the connection and correct SSID. However clicking the > applet no longer shows an active connection section. No way to disconnect. > >There is a previous connection (also no 'unknown connections' > section) but it had nothing useful (just a connection out of my list not > used for years). > >After a few minutes the SSID I was connected to showed up in the > 'previous connections' section - with a button to 'connect'. Clicking > that, the connection was killed and re-establihsed and the 'active > connections' section re-appeaed with the connected SSID now visible. The > unkown connection section also re-appeared. > > For those not yet using this you may want to wait a while until it > matures more. You did, of course, file bug reports for all those issues, so that they will be fixed in the upcoming release. Technocratic terms like "software maturity" are wonderful at making you forget how things actually work... -- Gaetan
Re: [arch-general] Upgrade problem
[2013-09-30 09:15:50 -0700] Anatol Pomozov: > Hi > > On Mon, Sep 30, 2013 at 4:43 AM, Phil Dobbin wrote: > > I attempted to update yesterday (pacman -Syu) & I got this message at the > > end of the update: > > > > '(121/121) checking for file conflicts > > [#] 100% > > error: failed to commit transaction (conflicting files) > > filesystem: /bin exists in filesystem > > filesystem: /sbin exists in filesystem > > filesystem: /usr/sbin exists in filesystem > > Errors occurred, no packages were upgraded.' > > Follow these instructions > https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ More generally, I would like to remind you and anyone using Arch that they are expected to read the news items from our Web page before any upgrade. You can also get them as an RSS feed: https://www.archlinux.org/feeds/news/ or as a mailing list: https://mailman.archlinux.org/mailman/listinfo/arch-announce -- Gaetan
Re: [arch-general] Two things: TODO-list orphans in [community] and switching over to git
[2013-09-29 17:33:52 +0200] Alexander Rødseth: > In connection with the newly created TODO lists for rebuilds of > packages formerly maintained by people that are no longer involved > with Arch Linux, I wondered if there would be any objections if I > moved the following packages from [community] to AUR: > > [...] > > As I gather, we all like git better than svn, for a long list of > reasons. Are there any objections to switching over from svn to git as > repositories for the official packages? This belongs to arch-dev-public. Not all developers and trusted users follow arch-general, but we are all expected to read arch-dev-public. Please repost it there in full. Also, please send two separate messages, one for each of your two points above, since they have nothing to do with each other. Cheers. -- Gaetan
Re: [arch-general] Two things: TODO-list orphans in [community] and switching over to git
[2013-09-29 17:33:52 +0200] Alexander Rødseth: > As I gather, we all like git better than svn, for a long list of > reasons. Are there any objections to switching over from svn to git as > repositories for the official packages? The reason to stick with SVN has always been that certain devs/TUs want partial checkouts. I'm all in favor of GIT myself, but I'm not sure what changed since we last discussed this. -- Gaetan
Re: [arch-general] Fwd: Proposal for the static library problem in Arch
[2013-09-28 22:25:55 +0100] Dan Liew: > On 28/09/13 19:27, Gaetan Bisson wrote: > > [2013-09-28 15:26:56 +0100] Delcypher: > > > I am strongly against this proposal. > > For many reasons, including those in the page Allan pointed to, dynamic > > libraries should be the default on Arch systems, and they should be the > > only supported type of library. > > Which page did Allan refer to? I cannot see a reply from Allan in this > thread. Right; it was in the "glibc 2.18-5 question" thread: http://www.akkadia.org/drepper/no_static_linking.html -- Gaetan
Re: [arch-general] Fwd: Proposal for the static library problem in Arch
[2013-09-28 15:26:56 +0100] Delcypher: > For popular packages that have can build static libraries and shared > libraries, build both but put the static libraries into their own > "*-staticlibs" package and the *-libs" packages should contain only > shared libraries. For example for boost you would have > > boost : Development headers + other files > boost-libs : Boost shared libraries > boost-static-libs : Boost static libraries I am strongly against this proposal. For many reasons, including those in the page Allan pointed to, dynamic libraries should be the default on Arch systems, and they should be the only supported type of library. Users who wish to build and use static libraries are of course free to do so, but should not expect Arch will do this work for them. Splitting packages as you suggests puts more burden on the developers, build process, and mirror bandwidth - with very few users benefiting. But, hey, that's fine: there is tons of great stuff in the AUR which is not officially supported by Arch Linux, simply because we do not have the resources to support everything - so we just focus on what most people care. And anybody is free to come along and "unofficially" support anything else... -- Gaetan
Re: [arch-general] glibc 2.18-5 question
[2013-09-26 15:15:12 +] LANGLOIS Olivier PIS -EXT: > So, out of curiosity, how big is the threat since I am under the impression > that almost 100% if not 100% of Arch binaries uses libc.so People are free to build static libraries on Arch and use them. There are probably not many who do that, but that does not mean we should not care for them. Some Arch packages even provide static libraries for convenience, such as gcc and glibc. And unfortunately a few higher-level packages also provide static libraries because their maintainers did not notice the waste of space... -- Gaetan
Re: [arch-general] Donate to Arch Linux
[2013-09-26 08:22:36 +0100] Anthony Campbell: > On 23 Sep 2013, Gaetan Bisson wrote: > > > > > > So first you ask whether donors can be anonymous and, even before > > getting an answer, you get carried away assuming that they can't?!? > > > > Most people are proud of sponsoring projects they like, and putting > > their names up is a way for the project to thank and acknowledge them > > back. If that's not your thing, you just have to say so... > > > I made a donation (from the UK via credit card) a few months ago > but my name has not appeared on the list, although I did not request > anonymity (no facility to do so as far as I remember). The SPI, who handles those things for us, has to let us know who has donated so we can update the website, and I do not believe they do this very often. I'll see what we can do about this. -- Gaetan
Re: [arch-general] Issue with systemd --user services
[2013-09-25 21:33:08 +0100] John Smith: > I'm having problems with starting 'mpd' as a user service: > > $ systemctl --user status mpd > mpd.service - Music Player Daemon >Loaded: loaded (/home/me/.config/systemd/user/mpd.service; enabled) >Active: inactive (dead) It would be awesome if there were some logs to tell us what happened... -- Gaetan
Re: [arch-general] Donate to Arch Linux
[2013-09-23 11:02:42 +0200] Ralf Mardorf: > 1. Do they care for "Arch Linux" as reference? You quoted the following bit: "When making a donation, please always notify the association at donation (at) ffis.de so we can track the transaction properly." In the email, just tell SPI: "The transfer of XXX euros I just did from YYY bank account is intended to support Arch Linux development." And the money will go where you want... You might additionally want to put "Arch Linux" in the comment field of the wire transfer. > 2. Will it be anonymous if wanted or is everybody listed as >"Past donor" at https://www.archlinux.org/donate/ ? If you wish the donation to be anonymous, just say so in the email. > It's very strange to list people who donated, at least if it's unwanted > by somebody who donated. > > If I donate to what ever and I want my friends to donate too, than I > send a request privately and let my friends know that I donated, but I > never ever would spend when it would be made public in general. If I > want to have it public, I'll do it myself. So first you ask whether donors can be anonymous and, even before getting an answer, you get carried away assuming that they can't?!? Most people are proud of sponsoring projects they like, and putting their names up is a way for the project to thank and acknowledge them back. If that's not your thing, you just have to say so... Cheers. -- Gaetan
Re: [arch-general] Thunderbird unread message count
[2013-09-19 15:35:20 -0400] David Rosenstrauch: > Having one small issue with the new Thunderbird (v24.0) upgrade. Discussing bugs on this list is pointless; please do not do it. Rather, submit a bug report to our tracker or, better yet, upstream's. This is the only way anything will ever get fixed. -- Gaetan
Re: [arch-general] sysctl.conf.pacsave messages of archlinux.org and archlinux.de are different
[2013-09-18 10:39:55 +0200] Ralf Mardorf: > archlinux.org claims "If you never customized /etc/sysctl.conf, you have > nothing to do", while archlinux.de's claim is that only those settings > > "# Protection from the SYN flood attack. > net.ipv4.tcp_syncookies = 1 > # Disable packet forwarding. > net.ipv4.ip_forward = 0 > net.ipv6.conf.all.forwarding = 0" > > were used by a /etc/sysctl.conf that never was customized. These were the only *uncommented* settings in our old sysctl.conf but, since they are kernel defaults now, there is no need to put them in any sysctl conf file anymore. The meaning was probably lost in translation, which is not surprising as in German it is hard to make precise statements with great accuracy. When in doubt, always trust the one true original archlinux.org. :) -- Gaetan
Re: [arch-general] System-Wide Pulseaudio
[2013-09-06 21:37:02 +0200] arnaud gaboury: > Please leave the whole conversation so everyone can follow from the > beginning. The best practice really is to trim your quote down to only the bits that are relevant to your reply. Like I just did. -- Gaetan
Re: [arch-general] arch rollback machine
[2013-08-24 10:51:20 +0100] Leonidas Spyropoulos: > On Sat, Aug 24, 2013 at 8:35 AM, Florian Dejonckheere > wrote: > > I'd be interested in joining the maintenance team. > me too Peter obviously had something useful to contribute to this list. Now, wishing that you were on the team gets nothing done. Either send Peter your sysadmin resume, discuss organization issues here, or get your hands dirty actually doing something useful... -- Gaetan
Re: [arch-general] 64 bit kernel with 32 bit userspace
[2013-08-21 06:22:54 +0200] Magnus Therning: > > https://bbs.archlinux.org/viewtopic.php?pid=1314594 > > Slightly unrelated, but is that link supposed to work? For me it's > "incorrect or outdated". It's the BBS' way of saying you have to log in... -- Gaetan pgp9GF9Wvl0w2.pgp Description: PGP signature
Re: [arch-general] The new mupdf package doesn't have the 'mupdf' file
[2013-08-17 17:25:11 +0800] Iru Cai: > After I updated mupdf, I found that /usr/bin/mupdf is missing, and is > replaced by mupdf-x11, which is a little inconvenient. Can the maintainer > add a mupdf link to it? mupdf-curl is a little fancier: it can render PDF while downloading them (of course this only works to some extent). Since we do not care for the curl dependency, it is preferable to mupdf-x11 in every respect. Note that I had to use `make CURL_LIBS='-lcurl -lpthread'` to get it to build with git master a while ago. -- Gaetan
Re: [arch-general] Disabled asm in x264 on i686
[2013-08-02 07:46:39 +0200] Jens Arm: > Why are asm optimizations disabled in x264 on i686? Here is the relevant commit: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/x264&id=a7a9241e6d0e7825c0baf333c49ea080e45a6c02 Unfortunately the log "update to latest commit" is not very helpful; I'll add its author as Cc: since I am not sure if he follows this list. -- Gaetan
Re: [arch-general] Upstream urls and package descriptions
[2013-08-01 18:02:38 +0200] Karol Blazewicz: > The same upstream url can be used by many packages and standardizing > would make it a bit easier to find which packages need to have the > upstream url updated. That is just not feasible. As you noticed yourself: sometimes, a www prefix and/or slash suffix to a URL are required, sometimes not. Certain upstream projects have several websites; others use a language different from English on their main page, but have an English subpage available (what page would you link to then?), etc. > I don't know if maintainers should write package descriptions or > should they just take them from upstream, but IMHO e.g. > https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-virus/ > : 'Description:Virus' > has to go. For this and everything else that follows, please open separate bug reports or feature requests in our tracker - except for: > Some language-related packages use the same description for all of them e.g. > xpdf-korean - Encoding information to use specific character sets in > Xpdf; does not include fonts > vim-spell-af - Language files for Vim spell checking That's fine to me (obviously, I maintain them): they're split packages that all do the same thing and I do not think the redundant description causes any confusion of what package is meant for what language... > Should language files always have a description that says which > language do they represent or are package names enough? Just calm down. Anything that makes sense is fine. :) -- Gaetan
Re: [arch-general] Upstream urls and package descriptions
[2013-08-01 20:23:18 +0200] Karol Blazewicz: > Should I open a single report for the base package e.g. > libreoffice-i18n and list which split packages need to be fixed or > open a report for each split libreoffice-* package? One report per pkgbase is good. -- Gaetan
Re: [arch-general] CLI diffing tool other than Vim?
[2013-07-30 18:41:00 -0400] Leonid Isaev: > Please guys... you only add more work for the moderators. Thanks for caring. They were whitelisted, but not anymore. It's the prisoner's dilemma: when a discussion goes nowhere, the clever choice is to stop replying. Replying anyhow might get you the last word (which may seem important to people not used to discussing by email) but if more than one person replies then it's the worst for everyone... -- Gaetan pgpffAxlxOjXT.pgp Description: PGP signature
Re: [arch-general] CLI diffing tool other than Vim?
[2013-07-30 10:32:40 +0100] Paul Gideon Dann: > On Tuesday 30 Jul 2013 10:58:21 Chris Down wrote: > > On 2013-07-30 09:43, Paul Gideon Dann wrote: > > > I run a couple of Arch servers, and I'm trying to teach someone how to go > > > about maintaining it (for when I'm not around). The difficulty is that > > > when it comes to package updates that require merging .pacnew files, I > > > always use Vim to merge changes. That's quite a steep learning curve to > > > impose on someone who's not all that familiar with a UNIX environment > > > yet. Does anyone know of any good & simple(ish) alternative for merging > > > files over SSH? > > Well, what merge programs are they familiar with? If it is vimdiff that > > poses the problem for this user, you might consider running meld instead. > > Thanks Chris, but this is a headless server; Xorg is not installed, so meld > is > out. You could mount the server's filesystem locally using sshfs and run meld on that. But in my opinion learning to use a powerful text editor is really a must for system administrators... -- Gaetan
Re: [arch-general] Apache PID File not readable
[2013-07-29 18:39:09 +] LANGLOIS Olivier PIS -EXT: > Wow, this thread has just made me realized that there was a run directory in > root dir. That happened a year ago. See: https://mailman.archlinux.org/pipermail/arch-dev-public/2011-December/06.html -- Gaetan
Re: [arch-general] What dirs are good to put in a tmpfs?
[2013-07-25 12:28:59 -0600] Chris Moline: > very slow network connection when I'm running deluged Look up "qos" (quality of service): Linux can be configured to prioritize sending small packets over larger ones. Small packets correspond almost exclusively to interactive connections... -- Gaetan
Re: [arch-general] How to safe configs to another path than ~
[2013-07-25 10:35:11 +0200] Ralf Mardorf: > If I run > HOME=/home/rocketmouse/alt_profiles/1 xfce4-terminal --maximize > by xfce4-terminal > the path gets completely ignored, all settings still are stored > to /home/rocketmouse and not to the > path /home/rocketmouse/alt_profiles/1. Applications have different means of finding out what the HOME directory of a given user is. The HOME environment variable is just one of them. Other popular ones include the function calls getpwuid() and getpwuid(); they basically read the data from /etc/passwd so your only way to work around that and pretend having a different home directory would be to override those calls with LD_PRELOAD... -- Gaetan
Re: [arch-general] What dirs are good to put in a tmpfs?
[2013-07-24 21:27:11 -0600] Chris Moline: > I installed anything-sync-daemon but I have no idea what to sync. General question: isn't the effect of that software exactly the same thing as increasing the vm.dirty_expire_centiseconds kernel parameter? Except maybe in the case of a given application calling sync() all the time, but then it usually has a good reason to do so (such as the written data being too important to be in cache during a power cut). -- Gaetan
Re: [arch-general] Archlinux ISO signing
[2013-07-21 18:56:28 -0400] Leonid Isaev: > Is there a particular reason why the images themselves are signed as > opposed to only their checksum files? For instance, Fedora provides > sha256sums with inline sigs [1], and verifying image checksum + checksum file > signature is _much_ less CPU and memory demanding than verifying signature of > an entire image. Is it really? Because that's how OpenPGP signatures work internally: they first compute a hash of the content to be signed, and then sign that. The default hash in recent GPG versions is SHA256. The only slow down I could think of is if GPG first tries to compress the content to be signed, but this should not be the case with our ISOs... -- Gaetan pgpWIWnFbMBFj.pgp Description: PGP signature
Re: [arch-general] Why is netcfg again in [base]?
[2013-07-16 15:05:24 +0200] Karol Blazewicz: > On Tue, Jul 16, 2013 at 2:29 PM, Ralf Mardorf > wrote: > > On Tue, 2013-07-16 at 22:03 +1000, Allan McRae wrote: > >> it appears that netcfg is removed again > > > > Half-OT: > > Yes, earlier today there was an update available, now it isn't available > > anymore. Can I get it from somewhere else? I didn't update this morning > > and want to do it now. It's ok that you don't put it to the official > > repositories, but it would be nice if user still could use it, as long > > as it's possible. > > netcfg 3.1-4 is in the ARM. If Ralf knew what ARM stands for, he probably wouldn't have asked that question in the first place... So here it is: http://arm.konnichi.com/ -- Gaetan
Re: [arch-general] Why is netcfg again in [base]?
[2013-07-16 13:25:57 +0200] A Rojas: > why are my messages still moderated? See below. > If I understood correctly, when the moderation system was set up the > idea was that after the first message was accepted the address was > automatically whitelisted. That's incorrect. Only subscribers with a consistent record of constructive contributions get whitelisted. And the process is completely manual. > I have sent a few messages since then These two messages of yours are the first ones since January... > many times they are not relevant anymore when they are finally published. So far you've only posted three times in 2013; that's not "many times". And although your messages do not seem time critical to me, I would like to point out that your original one in this thread was received by our servers at 06:12 and accepted by me at 07:18 (both times UTC-04). Please do contribute constructively to this list and you will get whitelisted eventually. -- Gaetan
Re: [arch-general] Wrapper for yaourt and pacman
[2013-07-13 23:16:25 +0200] Ralf Mardorf: > i=`pacman -Syu` does work, $i contains all packages Just use: `pacman -Syu --print --print-format %n` > How can I get a package list of the output "-Syua"? > > Btw. is there a way to get a cache for yaourt that isn't located > in /tmp? if not, then this would be one of the tasks the wrapper should > do. You should put those questions to the yaourt user list. -- Gaetan
Re: [arch-general] xdelta3 not updated for i686
[2013-07-13 14:09:18 +0200] Karol Blazewicz: > On Wed, Jul 10, 2013 at 7:15 PM, Karol Blazewicz > wrote: > > https://www.archlinux.org/packages/differences/ says that xdelta3 has > > not been updated for 32-bit - why? > > https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/xdelta3&id=2a27ff1daadfc44b00e10acd8f32dc9661a6e8a5 > > https://www.archlinux.org/packages/community/i686/xdelta3/ > > > > > > BTW, if Allan is not the maintainer anymore, the PKGBUILD should be > > updated to reflect this: > > https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/xdelta3 > > Bump. > Found the bug report that says xdelta3 3.0.7 does not compile in 32bit > architectures: http://code.google.com/p/xdelta/issues/detail?id=161 > After applying the patch, it compiled fine: > http://code.google.com/p/xdelta/issues/attachmentText?id=161&aid=1610001000&name=regtest_size_t&token=b_S_bl9eNoGNP6T5ULMzJHPBh3c%3A1373713816675 > > I did a small test (creating and applying deltas), seems to be working OK. > > > Should I post this in the bugtracker? Yes. This way you are sure: - to get the maintainer's attention; - that your issue will be properly tracked and won't require "bumps". -- Gaetan
Re: [arch-general] Arch Linux on servers?
Obviously, I am biased, but... [2013-07-09 11:13:08 +0100] M Saunders: > After installation you just want security and critical bug > fix updates for software, and not major version bumps, right? If you are prepared to stick to a given feature set, maybe. Then, you might be able to achieve near-absolute stability with a Debian-stable- like system. Now, in my experience, that makes any upgrade extremely painful, so I would definitely not recommend this approach to anyone with an interest in recent software. On the other hand, Arch's continuous flow of upgrades proves to be quite reliable, so long as the system is updated with a minimum degree of attention. Besides, it avoids duplicating upstream work at the distro level (such as backporting security fixes): such work can never be perfect, and has indeed been the cause of major problems in the past (Debian's openssl entropy issue likely being the most famous). I run two small-scale servers with Arch, which I only upgrade with care and when I have available time to fix potential problems. My upgrading frequency goes from a couple of times a week to once a month. About once a year, I hit an upgrade that is not straightforward, and it takes me an hour or two to fix arising issue and perform it; that is about it. -- Gaetan
Re: [arch-general] "vi" just terminates on a 32bit machine
[2013-06-16 11:21:33 +0200] Manuel Reimer: > if I access one of my systems via "ssh" and try to use "vi" there, > then it immediately returns with exit status "1". The proper place to discuss this is our bug tracker: https://bugs.archlinux.org/ -- Gaetan
Re: [arch-general] [procps-ng] archlinux default sysctl.conf
[2013-06-13 19:58:06 -0500] Leonid Isaev: > After reading sysctl-related manpages in systemd, I started to wonder > about the logic behind /etc/sysctl.conf shipped with core/procps-ng. If one > follows systemd's conventions, this file should be in /usr/lib/sysctl.d and > mnemonically called something like "100-archlinux-default.conf". Also note, > that systemd currently doesn't document /etc/sysctl.conf at all... See: /usr/lib/systemd/system/systemd-sysctl.service This is the legacy location of the kernel parameters configuration file. Eventually I would like to get most things out of it and to /usr/lib/... In the meantime it's fine as it is; if you have any specific issues or want a parameter to be taken out to /usr/lib please open a feature request. Cheers. -- Gaetan pgpRXBxrJUvjt.pgp Description: PGP signature
Re: [arch-general] uml_utilities dropped?
[2013-06-10 23:16:02 +0800] Brock Zheng: > I found that uml_utilities vanished in the repo. It can't be found > in core/extra/communit repo, and also AUR . Next time, please do a simple search before putting questions to this list you could have easily answered yourself... https://encrypted.google.com/search?q=site:archlinux.org+uml_utilities -- Gaetan pgpQXZ_PFsLm9.pgp Description: PGP signature
Re: [arch-general] Why is webkitgtk2 flagged out of date?
[2013-06-10 01:29:05 +0200] Karol Blazewicz: > https://www.archlinux.org/packages/extra/i686/webkitgtk2/ > Flagged out-of-date on 2013-03-27 > Last Updated: 2013-05-06 19:52 UTC Did you have a look at: http://webkitgtk.org/releases/ P.S. Did you expect an answer in the Subject field too? Please put your question in the body next time; it's not what the Subject field is for. -- Gaetan
Re: [arch-general] Arch, IBus, and Rime: IBus engines are not switched
[2013-06-07 08:06:01 +0200] Julius Adorf: > Do you have a clue how to make IBus change to the right engine after > switching input methods? Wouldn't you agree that's a question for an IBus support mailing list? -- Gaetan
Re: [arch-general] /bin symlink breaking fetchmail
[2013-06-06 22:20:46 -0400] Scott Lawrence:
> In short, the latest upgrade seems to have borked fetchmail:
>
> fetchmail: Error writing to MDA: Broken pipe
>
> Deleting the /bin symlink and creating a /bin directory containing
> only a symlink /bin/sh pointing to /usr/bin/bash, makes fetchmail
> work again.
>
> Running `strace -vf fetchmail` reveals that the execve("/bin/sh"...)
> call returns EPERM.
Please create a report on our bug tracker so this issue gets
assigned to the relevant packager and eventually fixed...
> Has anybody encountered this?
There is really no point looking for "bug buddies": this has never
(and will never) fix problems. Reporting them to our tracker does.
--
Gaetan
Re: [arch-general] Postfix and libsasl2.so.2 or libsasl2.so.3
[2013-06-01 13:05:54 -0400] Dave Ariens: > Is there an issue with the current postfix package? No. > # pacman -S postfix dovecot Do `pacman -Syu` before; partial upgrades are not supported. And next time please at least tell us which versions of which packages you are talking about (postfix, libsasl) to save us from guessing. -- Gaetan
Re: [arch-general] [arch-dev-public] Adding !staticlibs to our default makepkg.conf
[2013-05-29 20:24:14 +0300] Hussam Al-Tayeb: > Why not check first which applications build with --disable-static? 99% of all applications use autotools and therefore support this. Now do you really feel like adding an extra line to every PKGBUILD in our repository is neater than just enabling an option in makepkg.conf?!? -- Gaetan
Re: [arch-general] [arch-dev-public] Finishing the /usr move
[2013-05-29 09:30:18 +0100] Paul Gideon Dann: > On Wednesday 29 May 2013 18:13:01 Allan McRae wrote: > > Yes - /sbin, /usr/sbin and /bin will all point at /usr/bin. So > > hardcoded paths will not matter. Only file locations will. > > Just a little curious: does someone know what the reason is that we're moving > everything to /usr/bin instead of /bin? Is there any significant advantage > nowadays to having a separate /usr? I can understand a separate /home, /srv, > or /var far more... This has been discussed many times in the past. All you had to do was make a simple search before putting your question to this list... https://encrypted.google.com/search?q=archlinux+/usr/bin+move -- Gaetan
Re: [arch-general] What is the policy regarding the urgency of fixes ?
[2013-05-01 10:54:40 -0400] Pavan Yalamanchili: > Subject: [arch-general] What is the policy regarding the urgency of fixes ? Do you expect replies in the Subject field too? We all agree on ground rules which are clearly stated in the wiki (for instance: avoid patches that are non-critical or have not been approved upstream). However the precise interpretation of these guidelines is left to individual packagers. You should simply contact that in charge of the package you brought up. -- Gaetan
Re: [arch-general] zsh-history-substring-search with grml-zsh-config
[2013-04-09 09:21:24 +0200] f gr: > Excerpt from Oon-Ee Ng's message > of 2013-04-09T11:23+0800: > > > I use grml-zsh-config and after a recent update > > zsh-history-substring-search seems to have stopped working (up and > > down no longer search for the substring). > > > > Anyone with the same experience, or an a alternative? I really > > don't grok zsh =( > > I use both grml-zsh-config and zsh-history-substring-search; it seems > OK here. I don't grok zsh, too. I hope you both realize that this discussion is quite pointless without specific version numbers, and will provide more context in the future... -- Gaetan
Re: [arch-general] Is makepkg completely broken in pacman 4.1 ?
[2013-04-01 10:40:06 +0200] fredbezies: > So I reported a bug : https://bugs.archlinux.org/task/34542 > > Did anybody get this too ? And what is the point of posting here? You already reported this to our bug tracker, which is where any discussion should take place. Stop looking for other people experiencing the same issues as you: it is utterly pointless; just diagnose them, report them, and get them fixed. -- Gaetan
Re: [arch-general] [arch-dev-public] BIND10? No, thanks.
[2013-03-20 15:44:35 +0100] Armin K.: > On 03/20/2013 03:39 PM, Gaetan Bisson wrote: > >[2013-03-20 15:14:19 +1100] Gaetan Bisson: > >>Deprecation of bind and dnsutils > > > >I've just moved dnsutils to [extra] and orphaned it as well as bind. > >This announcement is postponed as long as somebody can manage to keep > >BIND alive... > > Why not keep bind9? Feel free to keep it in the AUR when it gets dropped there. -- Gaetan
Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory
[2013-03-17 15:42:55 +0200] Gesh hseG: > Also, this move was publicized in the forums, IRC topic, mailing list and > front-page news. > Seriously, if you're updating a months-old system, you'd better go over the > front-page news, at the very least. Top-posting again?!? Feel free to spend five more seconds formatting your emails to arch-general; they get read by about two thousand people. Their combined time is definitely worth five seconds of yours. -- Gaetan
Re: [arch-general] error during update of qt4 and qt5
[2013-03-15 15:49:17 +0530] phani: > what to do about this? Send this report to the proper place: https://bugs.archlinux.org/ -- Gaetan
Re: [arch-general] [arch-dev-public] BIND10? No, thanks.
[2013-03-09 09:51:38 -0500] Genes Lists: >One observation - bind is the de facto standard and as far as I can > tell used by the majority of the root servers [1] (and the majority of all > major DNS servers according to wikipedia [2] and bind website [3] anyway > :-)). > >We may want to be cautious stepping away from the dominant DNS > software unless there is a sea change for the DNS community to do same. There is no sea change for the computer community to switch to Linux; yet, here we are. People use BIND because they do not know any better. >Anyway, I'd encourage that we try and stick with bind. ... for no reason at all except its popularity, and disregarding the arguments my original message gave for the switch? That's a really disappointing attitude from you. It is really beyond me why you would state your uninformed opinion having not read anything about the benefits of ldns+unbound+nsd when this information is available to anyone looking for it. Seriously, do you never think about the hundred of readers this list has? Wouldn't you think they'd much rather read an informed opinion than a vague concern from somebody who has done little research on the topic? Anyway, you are of course free to keep maintaining BIND in the AUR. -- Gaetan
Re: [arch-general] [arch-dev-public] BIND10? No, thanks.
[2013-03-09 21:37:01 +] Mike Cloaked: > Apologies for replying to my own previous post, but having read up a little > more about authoritative and caching/recursive namerservers - it seems that > a good alternative to bind (which I use on all my machines especially as a > local authoritative DNS server for local networking) would be to use nsd as > the pure authoritative nameserver in combination with unbound as a > recursive caching nameserver. Both are packages available in arch. Once > installed both have systemd service files, and it seems that setting them > up is not too difficult - and I already had ldns installed (presume from > the base install) so I guess having those three packages running would give > a pretty good alternative to bind/dnstools Thank you so much for finally doing some basic research. Let me make this entirely clear for everyone: - ldns and dnstools are query tools (their main use is to send a single DNS request to a resolving server, and display the request). - bind is a multi-purpose server. - nsd is an authoritative server. - unbound is a resolving server. We will simply remove dnstools from [core] and replace it by ldns where needed; additionally, I will stop maintaining bind and suggest people switch to nsd (if they were using bind as an authoritative server) or unbound (if they were using bind as a resolving and/or caching server). > it would be nice to know > if anyone is already using these and could post on how well they perform? No. This list is not a tea room. There is plenty of information showing that ldns+unbound+nsd perform very well (much better than bind in fact) available on the Web anyone can look up; do also note that three of the thirteen root nameservers have switched from bind to nsd in the past few years. And please just do keep using your research skills. -- Gaetan
Re: [arch-general] How to wait efficiently for a package to update?
[2013-02-08 15:28:06 +1100] Gaetan Bisson: > [2013-02-08 12:14:25 +0800] Oon-Ee Ng: > > So I'm checking out python-sympy for some calculations in the Robotics > > subject I teach and realized that a bug was recently fixed in git > > which is crucial to what I hope to use it for. python-sympy-git in the > > AUR and that's settled. > > > > Then I got to wondering, I only really want to use the -git version > > till the next release, but since python-sympy is no longer installed > > (conflicts) I wouldn't automatically get it unless I check every once > > in a while if version is > 0.7.2. > > > > I figured installing a blank package with nothing in package() named > > python-sympy and with version 0.7.2 would allow me to get notified > > when python-sympy-0.7.3 or later gets in the repos. Is this a good way > > of doing it, or are there better ways? > > I would take python-sympy-git's PKGBUILD, replace its pkgname by > python-sympy and its pkgver by 0.7.2git20130208. Build and install. ^ That's a 3. Well, you get the idea. -- Gaetan
Re: [arch-general] How to wait efficiently for a package to update?
[2013-02-08 12:14:25 +0800] Oon-Ee Ng: > So I'm checking out python-sympy for some calculations in the Robotics > subject I teach and realized that a bug was recently fixed in git > which is crucial to what I hope to use it for. python-sympy-git in the > AUR and that's settled. > > Then I got to wondering, I only really want to use the -git version > till the next release, but since python-sympy is no longer installed > (conflicts) I wouldn't automatically get it unless I check every once > in a while if version is > 0.7.2. > > I figured installing a blank package with nothing in package() named > python-sympy and with version 0.7.2 would allow me to get notified > when python-sympy-0.7.3 or later gets in the repos. Is this a good way > of doing it, or are there better ways? I would take python-sympy-git's PKGBUILD, replace its pkgname by python-sympy and its pkgver by 0.7.2git20130208. Build and install. -- Gaetan
Re: [arch-general] [arch-dev-public] [RFC] Add Wayland/Weston
[2013-02-08 09:13:20 +0800] Oon-Ee Ng: > On Fri, Feb 8, 2013 at 9:05 AM, Gaetan Bisson wrote: > > [2013-02-08 01:23:30 +0100] Sébastien Luttringer: > >> [4] I'm already existed by arch-general be closed again > > > > I cannot make sense of that sentence... > > > s/existed/excited then it makes much more sense =) Oh, and "be closed" ==> "being closed". I'm obviously not good at guessing... -- Gaetan
Re: [arch-general] Troubleshooting random crash
[2013-02-06 19:06:45 -0500] Andre Goree: > Not really too keen on downgrading a bunch of packages that might break > dependencies and provide a REAL mess. If I have to go through that long > process, I'd rather just reinstall -- which at this point I'm planning > to do anyways. Well, there is little point in posting to this list if you have no motivation to actually investigate the problem. For starters, you've upgraded Linux from 3.6.11 to 3.7.4 in the window when you report the issue appeared; from the symptoms you described, it's a likely suspect. Downgrading it is far from being a "REAL mess": you only need to downgrade/rebuild the external modules you really need (probably none). > In fact it seems > all system processes hang because no logs are produced after the issue > rears it's ugly head. Ah. So that would mean your issue is I/O related, then? > > So you produce nothing at work? > > Not sure if you're just being an ass or not, however if you aren't: > that has nothing at all to do with the issue and I merely wanted to > establish _why_ I was using btrfs on a machine that I have running at my > job -- which is _also_ inconsequential in the context of my email. If > you indeed were being an ass, congrats, you succeeded. Once you were done being offended, you could have looked for the meaning behind the words I used: that your "main work desktop" really qualifies as "a production server". But, of course, as you have so unequivocally declared, btrfs has absolutely "nothing at all to do with the issue". And your statement above implying that the problem is I/O related is just a coincidence. Reporting issues is worthless when speculation is substituted for hard data. For example, a good report would have gone: "I believe this issue is unrelated to btrfs being my root filesystem since, on another Arch machine running ext3, I observe the following identical symptoms: first, `ssh -vvv` hangs at exactly the same point; second..." > > How about looking at the system logs to see what your system was up to > > just before a crash? > > I've done that, with no real hints. That's the first thing any linux > admin does when confronted with an issue such as this, no? Sure. But your first post gave no indication that you did that. > Is there > perhaps a way to build Thunderbird with debug symbols or some kind of > logging? I seem to recall opening Thunderbird each time this issue has > showed up. Well it would be nice to confirm that it is indeed at fault; downgrading it is certainly not a "REAL mess" either. You can certainly also build it with debug symbols: in the PKGBUILD (or makepkg.conf), set CXXFLAGS='' LDFLAGS='' CFLAGS='-g' and remove the strip option. > I'm ready > to blame btrfs b/c that's the only issue I see with my setup -- I also > have a tough time running a virtual machine on this box which I believe > is also due to btrfs. Didn't you write just a few lines ago that btrfs "has nothing at all to do with the issue"? Wild guess: your thunderbird mail database is huge (just like the disk image of your virtual machine - although I cannot really know what you mean by "tough time") and your btrfs has problems dealing with such big files (for instance, because your filesystem nearly full). To confirm, start thunderbird with an empty profile (such as by renaming ~/.mozilla into ~/.mozilla.old) and see what happens. -- Gaetan pgp7Q6XRV_jcf.pgp Description: PGP signature
Re: [arch-general] Troubleshooting random crash
There are obvious gaps in your report; fixing them would be a good first step towards better understanding the problem. For instance: [2013-02-06 10:57:59 -0500] Andre Goree: > I believe this started happening after a recent update > but I can't know for sure and I can't really reproduce it... Give a window for when you started noticing the symptoms. See in /var/log/pacman.log what packages were upgraded then. Downgrade them and see if the issue persists. > Using another system, I'm able to > telnet to port 22 on the "frozen" box (I run ssh on this box) but cannot > get connected via ssh. What does "able to telnet to port 22" means? Do you get the SSH banner? If yes, when is the SSH connection hanged/interrupted (ssh -vvv)? What do the SSHD logs show on the server side? > I'm not actually using this box as > a production server, just as my main work desktop So you produce nothing at work? > Any tips on things I could set up to try to capture some sort of output > or perhaps a kernel dump (if it's the kernel crashing)? How about looking at the system logs to see what your system was up to just before a crash? -- Gaetan pgppcRmlSpt7M.pgp Description: PGP signature
Re: [arch-general] Steam License
[2013-01-31 16:01:18 +0100] Lone_Wolf: > https://mailman.archlinux.org/pipermail/arch-dev-public/2013-January/024354.html > > In that thread on arch-dev-public, the license from valve for the steam > client is discussed. > Sofar noone mentioned section C4, export controls. As far as I understand, Section B takes precedence over Section C, which starts "Except as expressly set forth elsewhere in this License...". P.S. Please subscribe to arch-dev-public if you are interested in such issues so that, in the future, you can reply directly in arch-general to messages there without breaking threads. -- Gaetan
Re: [arch-general] signature from "Thorsten Tpper " is unknown trust
[2013-01-29 04:51:49 +0100] Karol Babioch: > Am 29.01.2013 04:37, schrieb Gaetan Bisson: > > Dave's answer certainly misses the real question of why Thorsten would > > want an expiration date on his GPG key, > > Because its good and common practice. There are several reasons for > this, one of which is a compromise. When you got compromised and lose > your revocation certificate, too, the key will expire at some point in time. So instead of impersonating you for the rest of your life, the attacker who compromised your key can only do so for a whole year? Well, only a few hours generally suffice for them to cause terrible damage - that is certainly true with Arch's package signing infrastructure. Expiring keys trade ease-of-use for a fake sense of security, so better avoid them and actually secure your key and revocation certificates. > I'm not sure about GPG, but in case of X.509 it also helps to keep the > certificate revocations lists (CRL) short, as certificates, which are > expired anyway, don't have to be listed here explicitly. In my opinion, that's a moot technical point which does not concern GPG. Cheers. -- Gaetan pgpWhLTBHEXMy.pgp Description: PGP signature
Re: [arch-general] signature from "Thorsten Tpper " is unknown trust
[2013-01-28 23:36:48 -0300] Martín Cigorraga: > On Mon, Jan 28, 2013 at 6:05 PM, Dave Reisner wrote: > > > > > That's generally what happens when you put an expiration date on a GPG > > key and time passes up until the current time exceeds the expiration > > date. > > > > http://www.youtube.com/watch?v=DRMBxnxWiNQ Please. Dave's answer certainly misses the real question of why Thorsten would want an expiration date on his GPG key, but if that was what you meant to say just spare us the drama and say it. -- Gaetan
Re: [arch-general] Strange isse with my arch usb install
[2013-01-21 00:05:35 -0600] kendell clark: > Systemd-udevd: renaming network interface wlan0 to wlo2 See the thread starting there: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-January/024223.html Essentially, network devices now have funny names... Revert to classical names by doing: touch /etc/udev/rules.d/80-net-name-slot.rules -- Gaetan
Re: [arch-general] Protect a cron job from systemd
[2013-01-02 11:07:01 +0200] Dimitrios Apostolou: > Any ideas on how to instruct systemd to not kill it > when terminating crond? Indeed, cron daemon services should use KillMode=process. I'll implement that for cronie and push it to [testing] right away. If you use another daemon, please create a bug on our tracker. Cheers. -- Gaetan
Re: [arch-general] Troubles with ALSA
[2012-12-31 17:01:48 -0006] Jack Stanek: > I've been having problems with ALSA recently. I'm pretty sure what you are looking for is the `alsactl store` command; have you read: https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture -- Gaetan
