Bug#935814: still actual for lyx (version 2.3.3-3) in debian unstable

2020-12-09 Thread Christian M . Amsüss
Reading up on the linked "some folks still report" issue, I've repeated
the test with the Emoji character representing the German test word (not
repeated here for propriety; any emoji would do as they're all outside
the BMP).

Running the preview or export to pdf through pdflatex gave a warning:

> The path of your document
> (/tmp/lyxtest//)
> contains glyphs that are unknown in the current document encoding (namely ). 
> This may result in incomplete output, unless TEXINPUTS contains the document 
> directory and you don't use explicitly relative paths (i.e., paths starting 
> with './' or '../') in the preamble or in ERT.
> 
> In case of problems, choose an appropriate document encoding
> (such as utf8) or change the file path name.

(which only got fully readable when copy-pasted out; the symbol I tried
to avoid on screen looks like an empty rectangle), but still ran trough
correctly (ie. is not affected by the bug in question).

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature


Bug#935814: still actual for lyx (version 2.3.3-3) in debian unstable

2020-12-09 Thread Christian M . Amsüss
notfound 935814 2.3.6-1
thanks

> Can you give it a try in unstable?

Works for me with unstable, tested with German umlauts.

Thanks for the update
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying


signature.asc
Description: PGP signature


Bug#824136: libjaylink status?

2017-08-11 Thread Christian M . Amsüss
On Fri, Aug 11, 2017 at 06:15:24PM +0100, Jonathan McDowell wrote:
> It looks like 0.1.0 was released in December 2016. I'd like to get this
> into Debian as it's a dependency for OpenOCD 0.10.0; any plans to do so
> or can I pick up and update the git repo on Alioth myself?

I didn't follow up libjaylink development as I don't use it that heavily
any more and thus I missed the 0.1.0 release -- so if you have time to
work on this now, please feel free take over the ITP.

I just had a very brief look over the changes since I did the original
packaging, and as nothing structural changed, a tag merge should give a
working base package.

Thanks
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature


Bug#737003: conversion to pdf silently fails for big paper formats

2014-01-29 Thread Christian M . Amsüss
On Wed, Jan 29, 2014 at 01:26:04PM +0100, Vincent Fourmond wrote:
   Default resolution is 1 postcript point for 1 pixel. Hence you need
 an image of width or height 900 000. Even with a camera taking
 pictures of width 10 000 (ie a 80 MPixel camera), you still need 90 of
 those stitched horizontally to have problems ! I don't see how this
 could arise in real life.

the images i have at hand don't have resolutions set in the image
explicitly (would they be evaluated at all?), but give these results:

$ exiftool infile.jpg
[...]
X Resolution: 1
Y Resolution: 1
Resolution Unit : None
Software: Hugin 2013.0.0.4692917e7a55
[...]
Image Size  : 12032x3013
$ convert infile.jpg outfile.pdf
$ pdfinfo outfile.pdf
[...]
Producer:   ImageMagick 6.7.7-10 2013-12-22 Q16 http://www.imagemagick.org
[...]
Page size:  866304 x 216936 pts

i don't know if a jpg's resolution can be any more unspecified than by
unsetting the unit. ([1] suggests there isn't; if there is, let me know
and i'll try to get hugin to export a properly undefined resolution).

the math of this implies 72pts per pixel (1 pixel per inch if i'm not
mistaken), which makes the critical size achievable with common cameras
and 360° panoramas.

[1] http://www.fileformat.info/format/jpeg/egff.htm

 Maybe just a warning could do ?

i don't know in which situation such a warning could be more useful than
an error (for these purposes, i'd call everythin an error that makes the
program return nonzero), but even a warning would be an enhancement.

thanks for considering the issue
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#697816: annual ping: Christian M. Amsüss for 2013

2013-01-09 Thread Christian M . Amsüss
Package: debian-maintainers
Severity: normal

this is my annual i'm-still-here ping as a debian maintainer.

my details are unchanged, my key id is still D3A4BDE1.


signature.asc
Description: Digital signature


Bug#667311: fix ftbfs with GCC 4.7

2012-04-17 Thread Christian M . Amsüss
On Tue, Apr 17, 2012 at 02:00:10PM +0200, Matthias Klose wrote:
 +  * Non maintainer upload.
 +  * Fix build failure with GCC 4.7, introduced by Debian changes.
 +Closes: #667311.
 +
 + -- Matthias Klose d...@debian.org  Tue, 17 Apr 2012 13:53:37 +0200

please consider sponsoring my fixed version from mentors[1], it'd make it
easier for me to integrate with the other pending changes. if it's my
DMUA mishap that makes you not want to use it, just drop the line from
the control file and changelog.

otherwise, if that's not an option to you (eg because you don't want to
review my multiarch changes), please go ahead and upload your nmu,
provided it's ok with respect to the ongoing libboost transition[2].

(i forgot to cc you in my original reply, sorry about that; if you
missed it, please have a look at [3].)

regards
chrysn

[1] http://mentors.debian.net/debian/pool/main/o/opencsg/opencsg_1.3.2-3.dsc
[2] http://release.debian.org/transitions/html/boost1.49.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=667311

ps.: before this bug gets fixed and archived: the bug was introduced to
my bad editing of the Makefile rather than by upstream -- apologies
blaming him in the first place.


signature.asc
Description: Digital signature


Bug#583476: openscad ITP

2012-04-12 Thread Christian M . Amsüss
On Thu, Apr 12, 2012 at 06:30:33PM -0400, Scott Howard wrote:
 CGAL is in main now, does that mean your package can be also?

it can be. by the time i last updated the package, cgal wasn't updated
yet. i'll prepere a new debian version going to the proper repository.

 tests 168-379 fail - is that something to be concerned about?

no.

the tests are mixed -- some check the functionality of the openscad
language interpretation, serving as regression tests for the basic
functionality of openscad itself.

others target the visual representation -- that's why some elaborate
image comparison is done. these tests require presence of an opengl
rendering engine. such could be provided in the build environment by
running a virtual x server. most imporantly, though, these tests are
there to test whether openscad works on a particular graphics card.

on the long term, i'd like to have the tests split on those that require
graphics output and those that are just basic tests of the openscad
language, as to run only the latter and require all of them to pass --
but for the moment, the current setup provides an easy way to see when
things went wrong if they go wrong, and otoh doesn't spend too much time
as the test requiring grahics fail quickly.

 The changelog has lots of entries in it that says it has been released
 to unstable and experimental already, but I can't find it in the
 repos. Is this a new package or reviving of an old one? If it is a new
 one that has never been in unstable, you should get rid of the
 changelog entries saying that it was. You also should close this ITP
 bug in the changelog.

the packages were previously uploaded only to my own private server
archive.amsuess.com's unstable and experimental areas and to an ubuntu
ppa, from where they are already used.

i remember a recent discussion on mentors@l.d.o, which concluded that
some sponsors would like all the old changelog entries marked as
UNRELEASED if that version didn't make it, and yet others like it
collapsed. if the latter is your preferred way, i'll collapse them to a
single short message.

 I can sponsor it [...]

thank you. i'll prepare an updated package (to section main, with
changelog collapsed, standards version updated, and possible new lintian
warnings fixed), and notify you when it's ready.


signature.asc
Description: Digital signature


Bug#658551: wrong dependencies in 1.3.2-1

2012-02-03 Thread Christian M . Amsüss
Source: opencsg
Version: 1.3.2-1
Severity: normal

the version i uploaded today has wrong dependencies to libglew-dev: it
calls the packages by wrong names (libglew6-dev instead of
libglew1.6-dev), and the only right name (libglew-dev) is only available
in experimental right now. this results in the build servers rejecting
it for unfullfilled build dependencies.

it made it through my own pbuilder as that was configured erroneously
from a previous run to still use experimental packages.

a patch is prepared, but going though some tests before my second
upload.


signature.asc
Description: Digital signature


Bug#654999: please add Christian M. Amsüss to debian maintainers keyring

2012-01-07 Thread Christian M . Amsüss
Package: debian-maintainers
Severity: normal

please add my key from the attached jetring changeset to the DM keyring.
they uid i use for packaging is Christian M. Amsüss chr...@fsfe.org,
which is not the primary ID of of my key.

i am aware that i'm a bit minimal on the requirements (one debian
developer signature, one advocate, trustpath via
423DCC9B/363474D1/13DD3950 to 738FE081 which is signed by several debian
devs or via my old key 8F64B918, which is generally better connected),
but those minimal criteria should be met.
Comment: Add Christian M. Amsüss christ...@amsuess.com as a Debian Maintainer
Date: Sat, 07 Jan 2012 19:03:47 +0100
Action: import
Recommended-By: Steffen Möller steffen_moel...@gmx.de
Agreement: 
  http://lists.debian.org/debian-newmaint/2011/10/msg00041.html
Advocates:  
  http://lists.debian.org/debian-newmaint/2011/10/msg00051.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  mQINBE3RSlsBEADVmZrcFs584T0pNSAP1ErTG5dHYTnwyneTcQ053lscrK4szlJ1
  aINO4AT0UBUVB4KuxXEEPeUR99xgJ37pyuY7ni2AJHYzzl0RvZfTJgSTqjtHpnRn
  VBWazea7WzlIey44/M6H3RelZgobL7SMLhlb12nJcJEIE8YoV5fMzyHT15QCZ2lU
  ZI2MFs9VLQmFT32QpzN4N/rfEmEnjc/Js8wEQucSlxb2hi8KsVNGcTEEPubJyk3C
  lEHZBDtoLReEqCNyBlnSVBO+gx0gUHPFWFPXA1iyzXnO0CZkXcz179ykNJEDoohY
  zp4RG7QVC+mf6ri7Y3Ofvxp96QVSQFJbw+rBxaUwbfoCB1vpLmVchbjOKepWxSyM
  /j4nlbDj/jKLLkjelvwFUOT4U4AZ5rQCjNOxmVJWjp4blY/G6sWiFSTSenyiy3Bb
  cYhaqOzHO4YzNPWGCxO44nTWJ6v9R0EAL+ETVKmpvGs7eFNPboeCUElulJmk4Fgj
  x9nWk8BuHEoo6h4oQ8ja3RMnyvi+pgNS3bX8MqGQnCcTlNvDlRcfmMI1hLzrb+k5
  arwpXCw7cP8BdhElJLSy7X7rz529xIRUO3UJIfAtmWjVdRVwBzJWLWBfb332PdpN
  vZrOm21lGn8f/pm0TL71NB7qoXlpsGnSN+7ASXGlF4JW+PTANNbNhc/7xQARAQAB
  tCxDaHJpc3RpYW4gTS4gQW1zw7xzcyA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPokC
  QAQTAQgAKgIbAwUJCWYBgAIeAQIXgAIZAQUCTdJQewULCQgHAwUVCgkICwUWAgMB
  AAAKCRA5jRES06S94cDqEACuUt4qoWVUVo+Aq4eSlgEBEkt4H4v5jq+z4B5WN+W9
  Mibq5DhYuuUPnWqRqFRYmwQ9hJiPQRz2A+/xavBupfLf2tZ3LWp0s1IesK23CFvM
  jfnQW9KhKQhlsrmoODHsGrJQIBLIMS9ALgt37XeQ2IOwJfaebb7S0W9A6eYAjXN0
  mV8iMM3HNpNK2qb5a3ZA6ofvCOlRss4OzuZ4LuCJ14TMn2yyb/bE5jy3H4jNgPvY
  IIofd8LZxcWwip4Qwtf6YJzjAEUedvE0Ma/QmUvVb9Wi8sytO9cayjLS+45nTa+d
  ywu0X/alVZnkXLrSqnEz7CRCqpLXJT2GWiyFFFuL6haGktoGPZ/PfXnvymCr82oS
  CtBS92LRFmD+MtA4ExIkN2RL8Hlv0twAnOomnWEE/qjNEv1eAQVCpP6cpP9IqLpY
  aYd+XX6tbcMFFcgt8NiX2TXsCeuetP1zBQPiNf6xOQmFWdvypKpjBnLPryYyAKlV
  JaUY8W2BoJxr2+f/IxAowhYJcy9mB6Ikm0auv14Q6UagxPjbuuZYSQiEME/sDGY9
  tNViTg94xPH+oNB96kQvkY7cJ6DxP/l6hT4Ef2CWyBkxyg+i84g/GrX+7LdX8KAz
  DILjfjQzh3INASWRWBH2+OPvWfhYfKx8nu7z/ZBQ2tTNnKUiD6fja5vNKtPUTbIG
  +IhGBBARCAAGBQJN0UrzAAoJEF/vPz+PZLkYIWQAnjDK5joClEmxYO8z87OCPHe7
  +WddAKCEk3gCz4v0n1nJydY1T9ZQlISDAokBHAQQAQIABgUCTdVzHAAKCRAIYB36
  Qj3MmzunB/4nc85dS5XGwQmadyraRm8r+gcFgVnoTh3Xh2a0IaWNqMncxAayLCNF
  t5x7Vq5b8pBrPWNTr8sAo4PbWUtFfZdrqaEycZnG3K9Btrj9EFenlXqMKv9u3tpF
  342Uk3Wm0MUOqocBuB0qZIs30IOODRJAd0mmfUjFKAA8NuJldECBPFHlnlyrGMo9
  sIKqgWQjKTpZkB9NYMFBU/h7Xy6gwLG1VPlok6YMamW0n+w0+8vLNQZOxFRob8ST
  1+Gb5+H3yu9P6zu8363pgR0k0m40/XjKa9kswwYDR0eiyoHSUO/l6TOBk2GiQYkH
  xTz7XPEj9H4+w9N6gDwTOdrIjKpC2resiQJABBMBCAAqAhsDBQkJZgGABQsJCAcD
  BRUKCQgLBRYCAwEAAh4BAheABQJN0UrpAhkBAAoJEDmNERLTpL3hRn0P/Am6ng+G
  1u6LE1UEERAIhW2XyHRinoTajUcd0PFmCSPjX/qTXVK0Ss+nZOPClx6Cj3w8jULl
  KYyUaec4Lln+aKhlUC/WgjJOxSWBc2V+EpVvtAXNHsmYhn+xUrY2pkHYwUvc24vp
  czVExCIpcCwuJko+aVAgagHrW+hoJgMo25eizMNIp+ygiet23Won04xoDEsr7GXP
  xCzOCzDPK5zKOsGj3cXRozXdhuq37fSwuNKAHFTIytVr4PPWh6mfbESQtVvKayye
  cQBL5z5yTYwYH0SF2QsF7jZ4raI2u2ePHm/dSQZ6LfeVxDBppAup45G7XUptjhaQ
  nJOrK0Y29pNMC8QbdWc/2PJj6TYE/cArUE0PumSC6jJuygXEIUJ5AWwIjesTSU3X
  sHAu4Pb2RCa4ardpedEa0Lpy3qKcevh4f8VGbwZ8P9xrvtW/o1K9tld0CoYMC0US
  C4cEpS7cznDx89maGX6znNuHHFFsEW4AgOBEngwIhIJUfT6iF5CTvlxkKFDqPf77
  3PPR1AVANeRWt7gO16OCmAkN6uW69rSE+IBlz6K2Dc2ArdRWu3Sc/UpkJGY/Q8eD
  zat1w36GrMSS8iwZAuL94P8z+JoWGbBwvXDgQaYfKRnTSyLGwV4m/vfg0VxBv/uN
  8IRR1mk1qKQU7F1us6MtNfd5eSkjz+k1hDppiQEcBBMBCAAGBQJOnafkAAoJEJaA
  6+SpkZPiwL0H/2fsyu4gx568LID+3YxwHIyhapnTg0SOxJxmRKKJiB9i17eiWJAZ
  2QOqX39bJonPwERaUCPzSYLgJeMrlCVoV8zM/2hofyA4cCX2aFS/7UqsFtvyDbSq
  1Ra224RmlVTIFwIdpeiAvQFETUKiuuyz8GwLLjsEbnh7OmY/9F383csFjchqBEPi
  EWwjIAyaUQAYybdkokUn/5//whDoZAo05KulDMIyyxWIHM7wMBYgBBBeafPCD+fd
  iM1/tAAet9PMnqaVeaAYLZ3r0zsa98zKST1qrwoqwDuBuTMN9qx6k4SD4DGyI7pr
  hW52xUyUjs5sfGk76FW2rHb18+vlT2GD0MSJARwEEwEIAAYFAk6dqAAACgkQMfzn
  590HlGGVhQf/V4FBrhGUFA+cw+fVNb/geVzwajUnNVGvYzShS8FZeGiGXkCZJn/S
  7rEUIz4avNH4yR1jDdC5XQaSGOfQx/OdH1Sad0Jj3/k+JxRxhGI05qABY89NsVTO
  Bd7iBvXDhlnf5WCZOrjSew16IyJG/CAbr6xtmdhA3FPr5x0BKpo9VluX2+qUg8xy
  qhkbZovhPaA4ewI4lVoKQNSIpSTxqt19v8tCUGISgt9VP6TN5LevfFEJcJq9RNC5
  wAr+hMn7ZLEZQ/P3Uq5iF7gxsepDRoxzzJtQH+YoxzXp/1HbY/geVSC6vGWMLaNn
  IQRXMcbKOrtEHzWIPHg7WMlPX/2N5Yag8ohGBBARAgAGBQJOFLkvAAoJEGM6Ah9k
  V2jKqrQAn1Ejrdn2FPeLMrGMqJKwkmUlFa8RAJ9xA4MVYAJLZCVjlNsdHHF0ZZAj
  krQYY2hyeXNuIDxjaHJ5c25AZnNmZS5vcmc+iQI9BBMBCAAnAhsDBQkJZgGAAh4B
  AheABQJN0lCIBQsJCAcDBRUKCQgLBRYCAwEAAAoJEDmNERLTpL3hCC8QAMF3Q5+u
  vP/mK/KrBY2MkVnXtxQ2idgh39UonlDCd4apliktD/OYD4pbT67UO1AigH8Syl21

Bug#507521: arandr assumes widthxheight mode names, resulting in ValueError (was: arandr: fails during start because of ValueError)

2010-02-10 Thread Christian M . Amsüss
package arandr
found 507521 arandr/0.1.2-3
retitle 507521 arandr assumes widthxheight mode names, resulting in 
ValueError
thanks

On Tue, Dec 02, 2008 at 03:20:37AM +0200, Paavo Hartikainen wrote:
 arandr apparently does not like my RandR settings.

 [...]
   ValueError: invalid literal for int() with base 10: 'default'
 
 [...]
   xrandr --newmode default 78.8 1024 1040 1136 1312 768 769 772 800

this is due the way arandr currently parses xrandr output -- it relies
on the mode being set to the size of your screen.

as a workaround, name your mode 1024x768 instead of default and
everything will work fine.

to solve this problem, i'll have to rewrite the xrandr interface code to
use the --verbose output of xrandr. this will take some time; please use
the workaround described above until the next release which will fix
that issue.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#566037: arandr: diff for NMU version 0.1.2-2.1

2010-01-26 Thread Christian M . Amsüss
On Wed, Jan 27, 2010 at 01:33:19AM +0100, Jakub Wilk wrote:
 python should be in Build-Depends (rather than in
 Build-Depends-Indep), because it is indirectly called in the clean
 target.

thanks. fixed that in place as it was not uploaded yet.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#566037: arandr: diff for NMU version 0.1.2-2.1

2010-01-24 Thread Christian M . Amsüss
i've already had the change to python-support in my vcs (along with the
change to the new source format), just didn't push testing it until this
bug was opened.

the changes go further than the patch supplied: now the package lets
debhelper 7 rules automation do all the work (with a small workaround
addition in the clean target that can be dropped with the next upstream
release).

changes file is on [1], source file on [2]; please sponsor the upload!

[1] 
http://christian.amsuess.com/tools/arandr/files/debian/arandr_0.1.2-3_amd64.changes
[2] http://christian.amsuess.com/tools/arandr/files/debian/arandr_0.1.2-3.dsc

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#565166: epiphany segfaults randomly

2010-01-18 Thread Christian M . Amsüss
On Thu, Jan 14, 2010 at 10:12:27AM +0100, Sebastian Dröge wrote:
 gdb epiphany-browser
 run
 [wait until it crashes]
 bt

here we crash… (for sake of completeness, it was run -p)

#0  clearClipboardContentsCallback (clipboard=value optimized out, 
data=0x7fffda02cd80)
at ../WebKit/gtk/WebCoreSupport/PasteboardHelperGtk.cpp:133
#1  0x741c887a in clipboard_unset (clipboard=0xa7fa10) at 
/gtk+2.0-2.18.6/gtk/gtkclipboard.c:693
#2  0x741c88ec in selection_clear_event_cb (widget=value optimized 
out, event=value optimized out)
at /gtk+2.0-2.18.6/gtk/gtkclipboard.c:349
#3  0x740a7538 in _gtk_marshal_BOOLEAN__BOXED (closure=0xba0ab0, 
return_value=0x7fffbd80, 
n_param_values=value optimized out, param_values=0xbd06f0, 
invocation_hint=value optimized out, 
marshal_data=0x741c88d0) at /gtk+2.0-2.18.6/gtk/gtkmarshalers.c:84
#4  0x72e9c44e in IA__g_closure_invoke (closure=0xba0ab0, 
return_value=0x7fffbd80, n_param_values=2, 
param_values=0xbd06f0, invocation_hint=0x7fffbd40) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gclosure.c:767
#5  0x72eb0513 in signal_emit_unlocked_R (node=0x73e200, detail=value 
optimized out, 
instance=value optimized out, emission_return=value optimized out, 
instance_and_params=value optimized out) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:3247
#6  0x72eb176a in IA__g_signal_emit_valist (instance=0xa3df10, 
signal_id=value optimized out, detail=0, 
var_args=0x7fffbf30) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:2990
#7  0x72eb1dd3 in IA__g_signal_emit (instance=0x50001, 
signal_id=4117524130, detail=4160432512)
at /tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:3037
#8  0x741ae6cf in gtk_widget_event_internal (widget=0xa3df10, 
event=0xc12dc0)
at /gtk+2.0-2.18.6/gtk/gtkwidget.c:4767
#9  0x74106e66 in IA__gtk_selection_owner_set_for_display 
(display=0x70f000, widget=0x0, selection=0x1, 
time=363280776) at /gtk+2.0-2.18.6/gtk/gtkselection.c:729
#10 0x74ad48a8 in WebKit::PasteboardHelperGtk::writeClipboardContents 
(this=value optimized out, 
clipboard=0xa7fa10, data=0x7fffd96e76c0) at 
../WebKit/gtk/WebCoreSupport/PasteboardHelperGtk.cpp:152
#11 0x74accd15 in WebKit::EditorClient::respondToChangedSelection 
(this=value optimized out)
at ../WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp:213
#12 0x74deff12 in WebCore::Editor::respondToChangedSelection 
(this=0x7fffda369d40, oldSelection=...)
at ../WebCore/editing/Editor.cpp:388
#13 0x74f6f64c in WebCore::Frame::respondToChangedSelection 
(this=0x7fffda369800, oldSelection=..., 
closeTyping=value optimized out) at ../WebCore/page/Frame.cpp:1811
#14 0x74e1d800 in WebCore::SelectionController::setSelection 
(this=0x7fffda369c20, 
s=value optimized out, closeTyping=128, clearTypingStyle=value optimized 
out, 
userTriggered=value optimized out) at 
../WebCore/editing/SelectionController.cpp:156
#15 0x74f63a71 in 
WebCore::EventHandler::handleMousePressEventSingleClick (this=0x7fffda369d90, 
event=value optimized out) at ../WebCore/page/EventHandler.cpp:359
#16 0x74f63fe6 in WebCore::EventHandler::handleMousePressEvent 
(this=0x7fffda369d90, event=...)
at ../WebCore/page/EventHandler.cpp:427
#17 0x74f646eb in WebCore::EventHandler::handleMousePressEvent 
(this=0x7fffda369d90, 
mouseEvent=value optimized out) at ../WebCore/page/EventHandler.cpp:1263
#18 0x74aecd6c in webkit_web_view_button_press_event (widget=value 
optimized out, event=0xc12ae0)
at ../WebKit/gtk/webkit/webkitwebview.cpp:534
#19 0x740a7538 in _gtk_marshal_BOOLEAN__BOXED (closure=0x73b640, 
return_value=0x7fffcc30, 
n_param_values=value optimized out, param_values=0xb940d0, 
invocation_hint=value optimized out, 
marshal_data=0x47edc0) at /gtk+2.0-2.18.6/gtk/gtkmarshalers.c:84
#20 0x72e9c44e in IA__g_closure_invoke (closure=0x73b640, 
return_value=0x7fffcc30, n_param_values=2, 
param_values=0xb940d0, invocation_hint=0x7fffcbf0) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gclosure.c:767
#21 0x72eb01dd in signal_emit_unlocked_R (node=0x73c9a0, detail=value 
optimized out, 
instance=value optimized out, emission_return=value optimized out, 
instance_and_params=value optimized out) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:3285
#22 0x72eb176a in IA__g_signal_emit_valist (instance=0x9f4310, 
signal_id=value optimized out, detail=0, 
var_args=0x7fffcde0) at 
/tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:2990
#23 0x72eb1dd3 in IA__g_signal_emit (instance=0x50001, 
signal_id=4117524130, detail=4160432512)
at /tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c:3037
#24 0x741ae6cf in gtk_widget_event_internal (widget=0x9f4310, 
event=0xc12ae0)
at /gtk+2.0-2.18.6/gtk/gtkwidget.c:4767
#25 0x7409fae3 in IA__gtk_propagate_event (widget=0x9f4310, 

Bug#565166: epiphany segfaults randomly

2010-01-14 Thread Christian M . Amsüss
On Wed, Jan 13, 2010 at 05:59:29PM +0100, Sebastian Dröge wrote:
 could you get a backtrace of the crash(es) with gdb and webkit/glib/gtk
 debug packages installed? There are some different crashes I get too,
 all of them caused by webkit 1.1.18 and newer.

i installed

gdb
libwebkit-1.0-2-dbg
libglib2.0-0-dbg
libgtk2.0-0-dbg

is that enough to make the traces usable?

 Also, could you try if midori for examples crashes too for you?

indeed it does -- please reassign this as appropriate. i had strace
running on the last session, but it took half a day to crash, so it's
rather lengthy (150M, ~5M compressed) -- is there a way to filter or
reduce it (say, last 1000 lines or so) for the strace to stay usable but
get a bit smaller and maybe not reveal my complete browsing history?


-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature


Bug#523903: arandr only works with RandR 1.2 while unstable has RandR 1.3

2009-04-13 Thread Christian M . Amsüss
On Mon, Apr 13, 2009 at 02:28:20PM +0200, Yves-Alexis Perez wrote:
 I'm not sure how much the code needs to be adapted, but at the moment it's
 just useless, and upstream doesn't seem really aware of that (no new
 upstream version for the moment).
 
 Should arandr just be dropped? It was a nice tool, but…

i have just upgraded myself and seen this. i am in the progress of
writing a patch, which i expect to be just a line or two since 1.3 seems
to be fully compatible.

regards
chrysn


signature.asc
Description: Digital signature