Re: [arch-general] Chromium Favorites Bar Partially Inoperative
On 2016-01-31 18:11:24, Dutch Ingraham wrote: > (...) confirm chrome on awesome "right" (or 2ndary) monitor problems: This is an awesome + multi-monitor + chromium problem, not your graphics driver. folders in the bookmark bar do not track "pressed" status or track the mouse at all. I believe it's more of awesome + some dirty stuff chromium does that it gets away in most other window managers because those aren't as awesome as awesome is awesome. I have observed this for at least half a year now, on different machines, always chromium (or google-chrome) + awesome + multimonitor setup + using the "secondary" monitor. Another thing is that chrome likes to draw itself a couple pixes left and right of where it actually is so at times snaps into the wrong screen in awesome. Less awesome WMs will probably cover this chromium bug as well. Just like the scum browser at times wants to draw its own window decoration or implement its own window movement (drag the title bar) ignoring the WM. It's not surprising chromium gets it wrong, these devs are out of their native area of expertise when doing WM-level stuff and I hope one day they'll learn to leave their fingers off it. Regards, -Martin
Re: [arch-general] Cannot use monitor in 1920x1080 anymore
On 2015-04-04 11:29:26, "Pedro A. López-Valencia" wrote:
> On 30/03/15 06:24, Martin S. Weber wrote:
> >On 2015-03-30 13:08:11, Alfredo Palhares wrote:
> >>Any ideas how can I debug this problem further ?
> >Have a look at X's logfile, /var/log/Xorg.log. There should be messages that
> >say the modes
> >are being removed, and why (not enough Vram, some parameter out of range,
> >etc.). It's likely
> >warning or errors, so it should be among the output of egrep '\([WE]{2}\)'
> >Xorg.0.log.
> >
> >Good luck,
> >-Martin
>
> Hmmm... Martin, if you still have a Xorg.log it means you have a really old
> installation, or you installed syslog-ng and integrated it with journalctl,
> something that is not standard anymore. Heck, OpenSUSE just removed it of
> Tumbleweed, it's a sign of the times.
>
> Alfredo, as Arch uses systemd/journalctl, you need to use the command:
>
> journalctl -b0 _EXE=/usr/lib/xorg-server/Xorg
>
As evidenced by your reply, if you can see the file, it's so much easier to look
at and massage with base system utilities, thanks for the showcase; if it's not
there, one might wish it was.
Anyways, Alfredo, right, as Arch says you cannot configure your system,
you NEED, you absolutely MUST use journalctl to access your logs.
Happy Easter,
-Martin
Re: [arch-general] Cannot use monitor in 1920x1080 anymore
On 2015-03-30 13:08:11, Alfredo Palhares wrote:
> Any ideas how can I debug this problem further ?
Have a look at X's logfile, /var/log/Xorg.log. There should be messages that
say the modes
are being removed, and why (not enough Vram, some parameter out of range,
etc.). It's likely
warning or errors, so it should be among the output of egrep '\([WE]{2}\)'
Xorg.0.log.
Good luck,
-Martin
Re: [arch-general] syslog-ng + systemd-journald = no logs for syslog-ng
On 2015-02-15 15:50:49, Leonid Isaev wrote: > TL:DR: Syslog-ng in [extra] is kind of broken, so you'll need to a few steps > to > get it to work in your environment. > > 1. (...) > 2. (...) > 3. (...) > 4. (Re)enable syslog-ng.service and restart syslog. A cookie, a mug of hot steaming morning drink and a big thanks for Leonid Isaev. Indeed, that fixed the problem. Damn systemd induced quirks. Regards, -Martin
Re: [arch-general] syslog-ng + systemd-journald = no logs for syslog-ng
On 2015-02-15 08:34:23, Troy Engel wrote: > On Sun, Feb 15, 2015 at 3:37 AM, wrote: > > ## vanilla /etc/syslog-ng/syslog-ng.conf > > # grep -v '^#' /etc/systemd/journald.conf > > > > It sounds like syslog-ng doesn't understand where the source is - (...) In fact, you pointed me to the solution. Leonid was suspecting it, and your manual link actually confirmed it. The generated configuration file is "fine", the symlinks are there etc. Here's the relevant portion of the manual text: "If the host is running under systemd, syslog-ng OSE reads directly from the systemd journal file using the systemd-journal() source" (6.11, p96 :) Now, with journald.conf "Storage=None", this cannot work, obviously. systemd-induced design brainfuck spreading... why would one follow a file when you have a socket already in place for some 30 years. I'll have a more detailed look at Leonid's suggestion, as that seems to be the way to go. Thanks Troy.
Re: [arch-general] Display Manager issue
On 2014-09-16 07:57:33, Heiko Becker wrote: > > On 16.09.2014 07:28, Frank Zimmermann wrote: > >my DM is behaving strange. > > Can you maybe provide information which DM it is? Could be related to that. I see the same for quite a while. With Lightdm. I disabled xdm in the meantime and startx instead, which does not expose the same symptoms of X-fckup. > Did you change anything in the Xorg.conf files? Lol. This is arch. Of course we did. The transition "working" -> "not working" wasn't triggered by config editing but by a pacman -Syu though.
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Fri, Jan 03, 2014 at 07:06:31PM +0100, Timoth?e Ravier wrote: > On 03/01/2014 17:46, Martin S. Weber wrote: > (...) > > (...) > > Read e.g. this message from the author of SQLite and fossil about packager's > > need/want for splitting dynamic libs from projects using said dynamic libs > > (sqlite in that instance): > > > > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14153.html > > I'm not sure this issue is related to the current discussion, as he is > upset with distributions packaging old software with new one, something > never done in Arch as far as I know: > > I hate having to add silly work-arounds in the code to accommodate > > distributions trying to use an older SQLite with a newer Fossil. > yes, it's a diff issue, but shows how upstream & packagers have a diff angle of view onto the subject. > > IMHO you're just about to open a can of worms that only you yourself will > > want to swallow, for a) the greater good of squishing bugs and b) no change > > in the big picture. > > There is nothing to "swallow" here as there already is an option to > bypass parallel build. I'm not opening anything either as I'm just not > against the proposed change. It looks like a convenience change, which > does not really have arguments against it as it's just a default setting. hmm. As I said, I brought up my part, may the powers that be act wisely. Regards, -Martin
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Fri, Jan 03, 2014 at 04:44:05PM +0100, Timoth?e Ravier wrote: > On 03/01/2014 16:24, Martin S. Weber wrote: > > (...) > > As far as I know, MAKE_JOBS_SAFE and 'options="!makeflags"' are > packaging "tricks" to work around an upstream bug. I agree with that assessment. > Enabling parallel builds by default would only reveal bugs, which is a > good thing generally, thus I don't understand your objections. Yes, it is a good thing generally. I'm not sure 'objection' is the right term though, I'd like to think of myself presenting angles of view onto the subject that have been under-represented. Anyways, why I bring them up: From my experience _watching_ pkgsrc development (I have not been involved myself other than being a pkgsrc user for a decade, talking to devs from time to time, opening PRs etc.), upstream developers care for another thing than package maintainers. Yes, in the end, both want to deliver software to users, but ISTM upstream devs are annoyed by the partially religious appearing dogmas of the packagers (which the latter often have for good reason). While upstream devs are specialists for the domain of software they are writing, ISTM that packagers' domain of specialty does not overlap with upstream's. In other words, say, packager knows everything about toolchain, API and ABI compatibility, static vs. dynamic linking, etc.; while upstream dev does not know (as much). Sermons from packager from pkg systems A, B, C, D (e.g., pkgsrc, apt guys, arch guys, rpm guys, from different distributions & companies etc.) sooner or later provoke ignorance from upstream dev (which is, to me, humanly understandable). In other words again: you might find what you consider a bug, but upstream will not care, ignore your patches, not listen to you or simply get annoyed (witnessed instances of this before). Read e.g. this message from the author of SQLite and fossil about packager's need/want for splitting dynamic libs from projects using said dynamic libs (sqlite in that instance): http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14153.html Richard is a great sw dev (as witnessed by the artifacts he created or helped to create), but a packager has a different point of view, area of expertise, and might come to a different conclusion. And that's perfectly fine, to some extent. IMHO you're just about to open a can of worms that only you yourself will want to swallow, for a) the greater good of squishing bugs and b) no change in the big picture. I suppose _I_ know enough about the dist-dependant way of turning off parallel builds to scratch when it itches ... and I think I have presented a different angle onto the issue, my job is done :) Regards, -Martin
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Sat, Jan 04, 2014 at 01:07:47AM +1000, Allan McRae wrote: > On 04/01/14 01:03, Martin S. Weber wrote: > > On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote: > >> Am 03.01.2014 15:21, schrieb Martti K?hne: > >>> You can't expect every upstream to fix their autohell to conform to > >>> our expectations here. > >> > >> So, we keep repeating ourselves. > >> > >> There is the !makeflags option for PKGBUILDs to work around this problem > >> (which you would know if you read the thread). If a package is broken > >> with -j, this option helps. > >> > > > > netbsd / pkgsrc did switch to a more concurrent default for $MAKE_JOBS. > > > > MAKE_JOBS_SAFE=no is a way to turn it off. > > > > In current 'stable' pkgsrc, 590 / 11862 packages have it set (to no, > > i.e., not parallel build safe). > > > > Each predates someone running into the pkg not building for them while > > it built for others. > > > > You wanna find those inexplicably not building on some machines manually, > > again? > > > > Have fun. > > > > Why would it need done manually? You have already found us a list! > because for each new occurrence, it will have to be determined manually: concurrency brings non-determinism with it. Many of these pkgs built just fine (tm) for developers a, b and d (not only on, but also on multi-core and/or SMP machines) while it didn't for devs c, f, g, and, much worse, for users u, y and z. I mean, feel free to learn the sane default for (said 590) pkgs from pkgsrc, or consider the process that spans from 2007 until now, where pkgs still are flagged MAKE_JOBS_SAFE after the first user has run into them not building. Also, not each pacman pkg has a 1:1 mirror candidate in pkgsrc. IMHO, should make you pause and (re)consider for a moment. Kind Regards, -Martin
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote: > Am 03.01.2014 15:21, schrieb Martti K?hne: > > You can't expect every upstream to fix their autohell to conform to > > our expectations here. > > So, we keep repeating ourselves. > > There is the !makeflags option for PKGBUILDs to work around this problem > (which you would know if you read the thread). If a package is broken > with -j, this option helps. > netbsd / pkgsrc did switch to a more concurrent default for $MAKE_JOBS. MAKE_JOBS_SAFE=no is a way to turn it off. In current 'stable' pkgsrc, 590 / 11862 packages have it set (to no, i.e., not parallel build safe). Each predates someone running into the pkg not building for them while it built for others. You wanna find those inexplicably not building on some machines manually, again? Have fun.
