Bug#418016: Recent security update of libx11-6 (1.0.3-7) made opera segfault
Package: libx11-6 Version: 2:1.0.3-7 Severity: critical Justification: breaks unrelated software After upgrading libx11-6 to the security update as in version 1.0.3-7 made opera segfault every time I tried to start it. Downgrading to version 1.0.3-6 fixes it. Yes, I know that opera isn't open source, but I marked this bug critical because if the patch for the security fix causes opera to segfault, something looks _fishy_ with this patch and could propably cause other applications to break, too. But feel free to downgrade the severity of this bug, if you think the problem is inside opera. I will probably fill a bugreport for opera, too, which includes a link to this bugreport. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libx11-6 depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libx11-data 2:1.0.3-7X11 client-side library ii libxau6 1:1.0.1-2X11 authorisation library ii libxdmcp6 1:1.0.1-2X11 Display Manager Control Protoc ii x11-common 1:7.1.0-16 X Window System (X.Org) infrastruc libx11-6 recommends no packages. -- debconf information: libx11-6/migrate_xkb_dir: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git help: how to "checkout" silently?
Peter Baumann <[EMAIL PROTECTED]> schrieb: > Christian Perrier <[EMAIL PROTECTED]> schrieb: >> >> --OJWLbGElk4npXSe3 >> Content-Type: text/plain; charset=iso-8859-15 >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> >> For the purpose of various i18n tasks, I have a few scripts that check >> the GIT repository out. >> >> These sripts give a lot of output (see below). Is there some magic way >> to make this entirely silent (except stderr output)=A0? >> >> This is basically the output of a "git clone.". Maybe another >> command would be better suited? >> > > Do you reclone everytime? Why not just update your existing clone with > git-fetch (or git-pull, which will also update your working directory if it > is clean; but git-pull should only be run by cron if you didn't do any > development in this repo and you are just tracking what happens upstream). > > But notice that it will give you very much the same output as the clone, but > there was currently something merged into the master branch on git.git to > prevent this [1]. (After looking on the patch it seems to work only for > the native git proctocoll, but see below) > > One question, why do you use http for fetching/cloning? I'm not sure that on > alioth the native git protocol for annonymous is activated ([2] doesn't > mention it), but it is _way_ more efficient. Especially if someone repacks > the repository you have to download the _whole_ repo again, although you > already have every object. At least git+ssh works, so you could use git > over ssh to transfer the objects efficently if you have an account on > alioth. > After double checking and asking on irc I can confirm that alioth has anonymous git protocol enabled. I even updated the wiki page http://wiki.debian.org/AliothGit because it didn't mention the git protocoll. Regards, Peter Baumann > [1]: > http://git.kernel.org/?p=git/git.git;a=commit;h=3ddad98b74924d76116d05e7601ab1e163d68500 > [2]: http://wiki.debian.org/XStrikeForce/git-usage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git help: how to "checkout" silently?
Christian Perrier <[EMAIL PROTECTED]> schrieb: > > --OJWLbGElk4npXSe3 > Content-Type: text/plain; charset=iso-8859-15 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > > For the purpose of various i18n tasks, I have a few scripts that check > the GIT repository out. > > These sripts give a lot of output (see below). Is there some magic way > to make this entirely silent (except stderr output)=A0? > > This is basically the output of a "git clone.". Maybe another > command would be better suited? > Do you reclone everytime? Why not just update your existing clone with git-fetch (or git-pull, which will also update your working directory if it is clean; but git-pull should only be run by cron if you didn't do any development in this repo and you are just tracking what happens upstream). But notice that it will give you very much the same output as the clone, but there was currently something merged into the master branch on git.git to prevent this [1]. (After looking on the patch it seems to work only for the native git proctocoll, but see below) One question, why do you use http for fetching/cloning? I'm not sure that on alioth the native git protocol for annonymous is activated ([2] doesn't mention it), but it is _way_ more efficient. Especially if someone repacks the repository you have to download the _whole_ repo again, although you already have every object. At least git+ssh works, so you could use git over ssh to transfer the objects efficently if you have an account on alioth. Regards, Peter Baumann [1]: http://git.kernel.org/?p=git/git.git;a=commit;h=3ddad98b74924d76116d05e7601ab1e163d68500 [2]: http://wiki.debian.org/XStrikeForce/git-usage > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alioth repositories
Julien Cristau <[EMAIL PROTECTED]> schrieb: > Hi all, > > I just completed a run of "git-repack -a -d" over all the repos on > alioth. This has brought the disk usage of /git/pkg-xorg/ from over > 1.5GB to under 200MB. It should also make future operations faster as > there's less need for disk I/O wait :) > I guess we should do this regularly, or have a cron job do it when the > number of objects grows too big. See also [0] for some ideas about how > to do that. > > Cheers, > Julien > > [0] http://blog.madism.org/index.php/2007/02/21/123-git-tricks > I'm not sure I remember correctly but I think I've read on the git mailinglist that doing this in a cronjob on a repo which is in active use (pushed to) isn't the best idea. It could be that my memory is just wrong and it was git-prune which is unsafe but I want to mention it before you screw your repo bigtime. Regards, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upload of xserver-xorg-video-ivtvdev.git
Ian Campbell <[EMAIL PROTECTED]> schrieb: > > --=-D1gy/51lI0n3bCHCQUe3 > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > Hi David, > > I've just pushed a fix for #406032 (FTBFS on a bunch of architectures) > to xserver-xorg-video-ivtvdev.git. Thanks to whoever added me to > pkg-xorg on alioth which allowed this. > > Would you mind doing an upload? > > The repo doesn't seem to have an upstream branch (presumably because > upstream isn't x.org). What's the best way to create one do you think? > Perhaps something roughly like: > git branch upstream > rm -rf debian > git commit > > Is there some way to create a completely empty branch rather than one > parented off debian-unstable? Then I could just import the pristine > upstream source into that and merge it into debian-unstable? > > The package currently uses a fork of upstream with X.org 7 support but > I'm hoping to switch to the svn trunk at some point. Would creating two > branches be acceptable/necessary? i.e. upstream-xorg-7-fork and > upstream-trunk. I'd quite like to switch the debian-experiment branch > over to upstream-trunk. > > Cheers, > Ian. This should work. (But better try it out with a _copy_ of your repo. I don't know if this is the _correct_ way to do this. If someone knows a quicker/better way, please tell me) cd xserver-xorg-video-ivtvdev git checkout -b upstream # create the upstream branch :> .git/refs/heads/upstream # remove the sha1 from the # upstream branch git-ls-files -z|xargs -0 rm # remove every tracked file # now remove everything which is left (objects, ignored files, etc.) rm .git/index # remove the index tar -xvzf upstream.tar.gz # unpack upstream into current directory git add . # add everything git commit Merging this branch with any other branch will be a huge pain in the ass, because there is no common commit (merge base). You could expect massive conflicts, but it's just the first merge, after that it should work as expected. Regards, Peter Baumann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410060: xkb-data: ctrl:swapcaps doesn't work (fully) correctly
I could reproduce this behaviour on a etch machine at the university having a session which only starts xev and no windowmanager. I get no output for ++1 there, too. There are also some Sun PC's (Opterons) with sun keyboards. On that machine it works as expected if I run setxkbmap -layout us -option ctrl:nocaps I don't know if the xserver uses a different mapping for those sun keyboards. Perhaps this gives someone a clue what's wrong. -Peter Baumann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410060: xkb-data: ctrl:swapcaps doesn't work (fully) correctly
Package: xkb-data Version: 0.9-4 Severity: normal I'm having a strange problem concerning my keyboard setup. Let me describe: I have fvwm-crystal installed with 4 virtual desktops and setup a mapping by ++1 do move the active window onto the virtual desktop 1 (of course, pressing ++4 moves the window to desktop 4). If I setup my xkb config like this: $ setxkbmap -v Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols:pc(pc105)+us geometry: pc(pc105) it works as expected. But as I like to have Caps_Lock as an additional CTRL Key, I run $ setxkbmap -layout us -option ctrl:nocaps $ setxkbmap -v Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols:pc(pc105)+us+ctrl(nocaps) geometry: pc(pc105) and now Caps_Lock behaves like CTRL. I can move my window to every desktop *except* to desktop 1. That means pressing the keys ++1 does nothing. But pressing ++1 behaves as it should. (so does ++2..4) If I could do anything more specific to resolve this issue feel free to ask. -Peter Baumann I don't now if it's usefull, but I attached the output of xev pressing ++1 because ++1 had _NO_ output. [... snipping uninteresting stuff ...] KeymapNotify event, serial 15, synthetic NO, window 0x0, keys: 4294967218 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 29, synthetic NO, window 0x241, root 0x4d, subw 0x0, time 2618586448, (-321,-257), root:(780,588), state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 32, synthetic NO, window 0x241, root 0x4d, subw 0x0, time 2618586469, (-321,-257), root:(780,588), state 0x14, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False FocusOut event, serial 32, synthetic NO, window 0x241, mode NotifyGrab, detail NotifyAncestor ConfigureNotify event, serial 32, synthetic YES, window 0x241, event 0x241, window 0x241, (1101,845), width 178, height 178, border_width 0, above 0x8194ca, override NO PropertyNotify event, serial 32, synthetic NO, window 0x241, atom 0x191 (_WIN_AREA), time 2618591573, state PropertyNewValue FocusIn event, serial 32, synthetic NO, window 0x241, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 32, synthetic NO, window 0x0, keys: 2 0 0 0 32 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 32, synthetic NO, window 0x241, root 0x4d, subw 0x0, time 2618591841, (-321,-257), root:(780,588), state 0x1c, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: KeyRelease event, serial 32, synthetic NO, window 0x241, root 0x4d, subw 0x0, time 2618591850, (-321,-257), root:(780,588), state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
