Re: [aur-general] (no subject)

2020-05-20 Thread Markus Schaaf via aur-general
Reply-To considered harmful. Maybe better strip DKIM? :-(


Re: [aur-general] (no subject)

2020-05-20 Thread Markus Schaaf via aur-general
Are you aware that you are posting these "test" messages to an English
language mailing list with many thousand readers? If you don't stop, you
will be banned.

Am 19.05.20 um 20:53 schrieb khashayar nazari via aur-general:
> لاین لطفا
> 


Re: [aur-general] TU application; freswa

2020-05-16 Thread Markus Schaaf
Am 16.05.20 um 21:01 schrieb Levente Polyak via aur-general:

> - shouldn't this package be named exfat-nofuse-dkms-git ? its not

Why would a fuse-filesystem use dkms? The whole purpose of fuse is to
run in user space. And renaming packages is an annoyance.

Just my 2¢, as a user of this package.

BR


Re: [aur-general] When to use optdepends

2020-05-14 Thread Markus Schaaf
Am 14.05.20 um 20:05 schrieb Eli Schwartz via aur-general:

> but the name of the plugin implies it's intended to be used for a
> specific type of command. If it's just a... general command
> runner?

It provides a toolbar and a bit of magic for *editing* latex files:
inserting images, item lists, formulas, bibliography etc. -- there is
also a button to "build" your document, with a customizable list of
external commands. But latex land is not very standardized. There is a
plethora of tools with a lot of overlap. Maybe rubber is king and
everything falls into place, when I get to know it better. Probably I
can decide which optdepends to suggest in half a year.

BR


Re: [aur-general] When to use optdepends

2020-05-14 Thread Markus Schaaf
Am 12.05.20 um 17:53 schrieb Eli Schwartz via aur-general:

> I'd generally expect an optdepends for something which the program
> has a built-in ability to use simply by installing the optdepends.

I'm sorry, but since you came up with the (IMO too clever by half)
suggestion to add optdepends, I expected a somewhat more elaborate
answer, considering the details of *that* package. The problem I have
is this:

The package defines a couple of custom commands for compiling (la)tex
to PDF and whatnot. (This is IMO a negligibility, because the main
purpose of that editor plugin is to provide tools for *editing* latex
files, not command suggestions for whatever task the author came up
with.) One such command sequence is:

rubber [...] --pdf "$filename"
gvfs-open "$shortname.pdf"

Now, rubber is like make, but for latex. And it's of the same
complexity. Please have a glance at the man page. What it does and
what programs it calls depends largely on the input (and
configuration). Like make it may potentially call a lot of different
programs. Even before considering which of these to include in
optdepends, I would need to know them. I don't use rubber, and by
cursory look I haven't found that information. The rubber package
itself does not optdepend on anything. Like the make package. Am I
supposed to find out? As the maintainer of an editor plugin? You could
depend on texlive, but texlive doesn't contain everything. One surely
needs more to compile something other than latex Hello-world.

This was the first line. The second is even better. gvfs-open calls
the preferred PDF-viewer. Should I decide which? Or suggest all I can
find?

Don't get me wrong. I'm not opposed to your suggestion to include some
helpful optdepends. It's just not *that* easy. Arch is not Debian. I
haven't looked, but Debian probably has a virtual package for
PDF-viewer and a list of candidates. Ubuntu has flavours where someone
decided which of these candidates it is. Even if Arch had flavours, an
AUR package would not.

This was only the first command. There are more. :-)

BR


[aur-general] When to use optdepends (was: AUR package q -- newbie)

2020-05-12 Thread Markus Schaaf
> It's not really clear to me when to optdepend.

Comments welcome. My idea is to use optdepends for things the user may
want, but it's not obvious how to make them work, like a glue-library
the application needs to use another facility, e.g. gpgme to use gpg, or
ghostscript to produce PDF.


Re: [aur-general] AUR package q -- newbie

2020-05-12 Thread Markus Schaaf
Am 12.05.20 um 13:54 schrieb Eli Schwartz via aur-general:

> On the other hand, this *would* seem like a good situation in which
> to use optdepends.

Thought about this. It's just a suggested/preset command line for a
user command. I don't use rubber myself. Why suggest to install it?
There is a command to process R files. Shall I suggest installing R,
too? The rubber tool itself doesn't optdepend on texlive, much like
make doesn't optdepend on binutils or gcc. It's not really clear to me
when to optdepend.

BR


Re: [aur-general] AUR package q -- newbie

2020-05-12 Thread Markus Schaaf
Am 12.05.20 um 13:03 schrieb Raj Kombiyil via aur-general:

> charm. If there's a place where I can upvote/something pl let me know.

Well, on https://aur.archlinux.org/packages/gedit-latex-git/ there is a
link "Vote for this package" on the right side, which is meant to count
active users, or such.

BR


Re: [aur-general] AUR package q -- newbie

2020-05-12 Thread Markus Schaaf
Am 12.05.20 um 05:40 schrieb Raj Kombiyil via aur-general:

> $git clone https:://AUR.archlinux.org/gedit-latex.git
> Thanks in advance for any pointers. Appreciate it.

BTW, this isn't the package I've uploaded, but the older you complained
about. The older one installs rubber and texlive-core, so I'm not sure
what your problem is. With my package and rubber installed, I can see
error messages from rubber in the bottom pane.

Do yourself a favour and use your new knowledge to install an AUR
helper. I like yay. Then use it like you would use pacman, e.g.
$ yay -Syu ; yay -S gedit-latex-git rubber texlive-core

BR


Re: [aur-general] AUR package q -- newbie

2020-05-12 Thread Markus Schaaf
Am 12.05.20 um 05:40 schrieb Raj Kombiyil via aur-general:

> Before, I could just write my .Tex file and Ctrl+alt+1 and will get PDF.
> pdflatex is installed via texlive-most pkg. Here, Ctrl+alt+1 doesn't do
> anything. What am I missing? Because install was not proper? $which
> gedit-latex says no gedit-latex in /user/bin etc.
> Now, gedit can see the plugins and I marked the plugin. And also enabled
> bottom panel where I see error messages. Here nothing comes. Any idea what
> I need to do? Since I am teaching a class, I guess wrong time to play with
> arch :(

If you look at the plugin's settings, there are a couple of commands
defined. One of which you are trying to use. The plugin's installation
doesn't depend on any of the programs that are setup by default for
these commands, because you may want to change them. Or not use all of
them. I wouldn't want to install R, for instance, just because the
plugin has commands to render *.rnw files. It's your responsibility to
install and setup everything, so the commands you use do what you want.
If you want to use the default rubber command, you need to install at
least 'rubber' and 'texlive-core'. The plugin does no magic. It just
calls a command. You may test the very same command in a terminal.

If you have never compiled a latex document on the command line, and are
not willing to learn it, then yes Arch isn't for you. Because the very
next problem would be finding out how to install additional latex
packages, that your document may use.

BR


Re: [aur-general] AUR package q -- newbie

2020-05-11 Thread Markus Schaaf via aur-general
Am 11.05.20 um 16:09 schrieb Raj Kombiyil via aur-general:

> https://aur.archlinux.org/packages/gedit-latex
> I see that in the comments section, there's some issue. The package is
> updated in 2017 last.

Since I'm using this plugin occasionally, I took the freedom to upload
https://aur.archlinux.org/packages/gedit-latex-git/

BR


Re: [aur-general] About bullying in our community

2018-10-31 Thread Markus Schaaf via aur-general
Am 30.10.18 um 21:48 schrieb Giancarlo Razzolini via aur-general:
> Em outubro 30, 2018 16:07 Ralf Mardorf escreveu:
>> Apparently this TU has got special rights. That he could behave like
>> this again and again does strengthen him to continue doing it.
>>
> This thread has lived much longer than it's purpose. Let's stop this
> right now.
> 
> I'm placing this list into emergency moderation if this continues.

I don't want to impute bad intentions to you, but this behavioural
pattern might be a root of the problem. This isn't a technical
discussion. It's about social interactions and emotions. You can't just
weigh facts and find /the/ truth. It's widely believed that the best we
have come up with, to reach consensus in large communities, is voting.
An equivalent on a mailing list would be to show support through
iterating a position in one's own words. What you have written above is
like trying to cut off a protest march on the grounds that the first 20
protesters already made their point clear, so there would be no reason
for the next 2000 to reiterate it again.

This thread might make some people feel uncomfortable. But rightly so.
This is not only about some TUs employing a harsh and repellent style of
communication. This is also about the community of TUs letting this
happen for years.

> I'm confident all the parties understood what happened by now and how
> to avoid this in the future.

I don't. What makes you so confident? I do believe in man's ability to
change. But this often needs a bit of pressure.

(Don't forget that moderation means to arbitrate, not to censor.)

Best regards


Re: [aur-general] Unresponsive maintainer (=TU)

2014-11-12 Thread Markus Schaaf
Am 12.11.2014 um 12:18 schrieb Fabio Castelli:

 Another package in the AUR called mysql-connector-c++, which unfortunately I 
 don't use, requires the mysql-clients package to be built without the no-rtti 
 flag.
 
 This is entirely the point here, I don't know why the mysql-connector-c++ is 
 unable to built without rtti. The same package builds fine using 
 mariadb-clients WITH no-rtti.
 
 I think the issue should be searched in the mysql-connector-c++ package, ...

I don't.  Using -fno-rtti to build a package that many other packages
may link to seems wrong.  It's a typical case of premature optimization.
 And it hurts, as is obviuous here.  That flags cripples the c++
compiler to a (non-standard) subset of the language, in non-obvious
ways: beside typeid, dynamic_cast and exception handling may work
differently (if at all).  The first is typically used in libraries like
boost::variant, which are useful in applications communicating with a
database.

As Marcel already noted:  To disable RTTI saves some kilobytes of
executable size. (Code size and working set size is unaffected.)  So it
buys really nothing, considering that other build flags used routinely
in Arch (-D_FORTIFY_SOURCE=2 or -fstack-protector-strong) are much more
costly.

Regards