Re: [Desktop-packages] [Bug 1322275] Re: lightdm sessions started by dm-tool lock (or a session locker) never get closed
> This is a glaring red sign that neither lightdm nor upstart are the > appropriate packages for this issue, but lightdm-gtk-greeter is. That still doesn't explain how I'm getting the problem with unity- greeter. There may be more than one bug at play here. Maybe my issue is better tracked by bug #1410584 (please don't merge it with this one until it's been established that they are in fact the same). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1322275 Title: lightdm sessions started by dm-tool lock (or a session locker) never get closed Status in Light Display Manager: New Status in lightdm package in Ubuntu: Confirmed Status in lightdm-gtk-greeter package in Ubuntu: New Status in upstart package in Ubuntu: Confirmed Bug description: dm-tool lock starts a new lightdm greeter (for unlocking) and a new logind session. After unlocking the greeter disappears, but the logind session never closes. loginctl session status c24 reports something like: c24 - lightdm (103) Since: Thu 2014-05-22 18:38:27 CEST; 30min ago Leader: 7872 Seat: seat0; vc8 Display: :1 Service: lightdm-greeter; type x11; class greeter State: closing CGroup: systemd:/user/103.user/c24.session └─7907 init --user --startup-event indicator-services-start This results in an accumulation of stale lightdm sessions after using e.g. a session locker for a while. I get this issue on a freshly installed and fully updated Xubuntu 14.04. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1322275/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1322275] Re: lightdm sessions started by dm-tool lock (or a session locker) never get closed
* Jonathan Sahagun [2016-01-29 12:51:08 +]:
> In this file:
> /etc/xdg/xdg-xubuntu/lightdm/
You probably mean /etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf
.
> In line 27, in a default installation, it reads:
> show-indicators=power;~session;~language;~a11y;~power;
>
> Remove the first "power" entry, leaving only the built-in indicators:
> show-indicators=~session;~language;~a11y;~power;
>
> Save the file, and any subsequent lock screens and the processes they
> spawn should now exit properly upon screen unlock.
Not for me, they don't. (I rebooted after making the change you suggested
and before testing it.)
> Can you see if this solves the issue on your computers?
Here it doesn't. Of course there may be more than one issue. Could you look
at the end of your /var/log/lightdm/x-1-greeter.log{,.old} files? I'm still
seeing unity-greeter crash instead of exiting cleanly:
[+85,90s] WARNING: unity-greeter: Fatal IO error 11 (Resource
temporarily unavailable) on X server :1.
In my case the lingering processes are mostly indicator-sound and
indicator-bluetooth, with pulseaudio occasionally showing up too.
I'd happily turn these off too (especially the Bluetooth one for
which our workstations aren't supposed to have any hardware) but don't
see how.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1322275
Title:
lightdm sessions started by dm-tool lock (or a session locker) never
get closed
Status in Light Display Manager:
New
Status in lightdm package in Ubuntu:
Confirmed
Status in upstart package in Ubuntu:
Confirmed
Bug description:
dm-tool lock starts a new lightdm greeter (for unlocking) and a new
logind session. After unlocking the greeter disappears, but the logind
session never closes. loginctl session status c24 reports something
like:
c24 - lightdm (103)
Since: Thu 2014-05-22 18:38:27 CEST; 30min ago
Leader: 7872
Seat: seat0; vc8
Display: :1
Service: lightdm-greeter; type x11; class greeter
State: closing
CGroup: systemd:/user/103.user/c24.session
└─7907 init --user --startup-event indicator-services-start
This results in an accumulation of stale lightdm sessions after using
e.g. a session locker for a while.
I get this issue on a freshly installed and fully updated Xubuntu
14.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1322275/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1322275] Re: lightdm sessions started by dm-tool lock (or a session locker) never get closed
Silly me, I had overlooked the fact that we aren't using the same greeter. I've got [SeatDefaults]greeter-session=unity-greeter in /etc/lightdm/lightdm.conf. So of course your solution didn't work for me. (I need to give users a choice of desktop sessions, and found unity- greeter to be better at remembering a user's last session.) You may have found a valid workaround for GTK greeter users; unfortunately I cannot switch to it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1322275 Title: lightdm sessions started by dm-tool lock (or a session locker) never get closed Status in Light Display Manager: New Status in lightdm package in Ubuntu: Confirmed Status in upstart package in Ubuntu: Confirmed Bug description: dm-tool lock starts a new lightdm greeter (for unlocking) and a new logind session. After unlocking the greeter disappears, but the logind session never closes. loginctl session status c24 reports something like: c24 - lightdm (103) Since: Thu 2014-05-22 18:38:27 CEST; 30min ago Leader: 7872 Seat: seat0; vc8 Display: :1 Service: lightdm-greeter; type x11; class greeter State: closing CGroup: systemd:/user/103.user/c24.session └─7907 init --user --startup-event indicator-services-start This results in an accumulation of stale lightdm sessions after using e.g. a session locker for a while. I get this issue on a freshly installed and fully updated Xubuntu 14.04. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1322275/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1322275] Re: lightdm sessions started by dm-tool lock (or a session locker) never get closed
unity-greeter has code to kill upstart, but for some reason this isn't being executed. My best guess is that unity-greeter often (if not always) dies before it exits the GTK main loop. Does it receive a second SIGTERM, or a SIGPIPE? (When lightdm says "Stopping display server, no sessions require it", I would think.) This should be testable. Amending my earlier comment #7, I do see "Got a SIGTERM" some of the time, but I hardly ever see "Cleaning up" (when unlocking; new logins are another story). Indeed upstart is not to blame: it shuts itself off cleanly when signalled; the problem seems to be that unity-greeter doesn't send out that signal as it is supposed to. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1322275 Title: lightdm sessions started by dm-tool lock (or a session locker) never get closed Status in Light Display Manager: New Status in lightdm package in Ubuntu: Confirmed Status in upstart package in Ubuntu: Confirmed Bug description: dm-tool lock starts a new lightdm greeter (for unlocking) and a new logind session. After unlocking the greeter disappears, but the logind session never closes. loginctl session status c24 reports something like: c24 - lightdm (103) Since: Thu 2014-05-22 18:38:27 CEST; 30min ago Leader: 7872 Seat: seat0; vc8 Display: :1 Service: lightdm-greeter; type x11; class greeter State: closing CGroup: systemd:/user/103.user/c24.session └─7907 init --user --startup-event indicator-services-start This results in an accumulation of stale lightdm sessions after using e.g. a session locker for a while. I get this issue on a freshly installed and fully updated Xubuntu 14.04. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1322275/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1322275] Re: lightdm sessions started by dm-tool lock (or a session locker) never get closed
I'm seeing the same problem (on multiple systems), and have been looking at the lightdm and unity-greeter log files in an attempt to understand what is going on. Some additional observations: * I see three processes survive the termination of the greeter session: init (aka Upstart), indicator-sound-service and indicator-bluetooth- service. The following children of the init process do terminate: indicator-messages-service, indicator-power-service, indicator-datetime- service, indicator-session-service, indicator-application-service. * If I send a SIGTERM to the surviving indicator-sound-service and/or indicator-bluetooth-service, the init process respawns a new one, and the event is logged in /var/log/lightdm/x-N-greeter.log(.old) . To fully get rid of the session I need to kill (-TERM is enough) the init process. If I do so, the children go away too. * The aforementioned greeter log does *not* say DEBUG: Cleaning up as I would have expected from reading the source code (and as seems to be happening on initial login). It does not say DEBUG: unity-greeter.vala:605: Got a SIGTERM either. Instead, I see: ---begin log excerpt--- init: indicator-bluetooth main process (21833) killed by TERM signal init: indicator-bluetooth main process ended, respawning init: indicator-power main process (21834) killed by TERM signal init: indicator-power main process ended, respawning ** (unity-settings-daemon:21845): WARNING **: Name taken or bus went away - shutting down init: indicator-datetime main process (21836) killed by TERM signal init: indicator-datetime main process ended, respawning init: indicator-sound main process ended, respawning init: indicator-session main process (21853) killed by TERM signal init: indicator-session main process ended, respawning init: indicator-application main process (21854) killed by TERM signal init: indicator-application main process ended, respawning init: indicator-messages main process ended, respawning init: indicator-power main process ended, respawning init: indicator-datetime main process ended, respawning init: indicator-session main process ended, respawning init: indicator-application main process ended, respawning init: indicator-messages respawning too fast, stopped init: indicator-session respawning too fast, stopped init: indicator-power main process ended, respawning init: indicator-datetime respawning too fast, stopped init: indicator-application respawning too fast, stopped init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power main process ended, respawning init: indicator-power respawning too fast, stopped [+1548,34s] WARNING: unity-greeter: Fatal IO error 11 (Resource temporarily unavailable) on X server :1. (unity-settings-daemon:21845): Gdk-WARNING **: unity-settings-daemon: Fatal IO error 2 (No such file or directory) on X server :1. ---end log excerpt--- (+1548,34s is 0.13 seconds after authentication completion. The comma is normal for this system's locale.) So it looks like unity-greeter is either not being sent, or not reacting to, SIGTERM. It does exit, obviously, but perhaps only as a side effect of the X server being shut down. According to /var/log/lightdm/lightdm.log a SIGTERM was sent to the lightdm --session-child process. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1322275 Title: lightdm sessions started by dm-tool lock (or a session locker) never get closed Status in Light Display Manager: New Status in lightdm package in Ubuntu: Confirmed Status in upstart package in Ubuntu: Confirmed Bug description: dm-tool lock starts a new lightdm greeter (for unlocking) and a new logind session. After unlocking the greeter disappears, but the logind session never closes. loginctl session status c24 reports something like: c24 - lightdm (103) Since: Thu 2014-05-22 18:38:27 CEST; 30min ago Leader: 7872 Seat: seat0; vc8 Display: :1 Service: lightdm-greeter; type x11; class greeter State: closing CGroup: systemd:/user/103.user/c24.session └─7907 init --user --startup-event indicator-services-start This results in an accumulation of stale lightdm sessions after using e.g. a session locker for a while. I get this issue on a freshly installed and fully updated Xubuntu 14.04. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1322275/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe :
[Desktop-packages] [Bug 1427360] Re: firefox doesn't open an url as argument
We've seen this too (on Ubuntu T). It started happening immediately
after the upgrade to Firefox 36. Other web browsers are unaffected;
e.g., if I set my preferred web browser to Lynx and click on a URL in
Thunderbird the link is being followed.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1427360
Title:
firefox doesn't open an url as argument
Status in firefox package in Ubuntu:
Confirmed
Bug description:
Since few days, Firefox doesn't open the url from Thunderbird or the
XFCE desktop.
It just opens the home page.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: firefox 36.0+build2-0ubuntu0.14.04.4
ProcVersionSignature: Ubuntu 3.13.0-46.76-generic 3.13.11-ckt15
Uname: Linux 3.13.0-46-generic x86_64
NonfreeKernelModules: nvidia
AddonCompatCheckDisabled: False
ApportVersion: 2.14.1-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: j 1882 F pulseaudio
/dev/snd/controlC1: j 1882 F pulseaudio
BuildID: 20150224134236
Channel: Unavailable
CurrentDesktop: XFCE
Date: Mon Mar 2 20:27:57 2015
ForcedLayersAccel: False
IncompatibleExtensions:
Français Language Pack - langpack...@firefox.mozilla.org
English (South Africa) Language Pack - langpack-en...@firefox.mozilla.org
English (GB) Language Pack - langpack-en...@firefox.mozilla.org
Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
IpRoute:
default via 192.168.0.254 dev eth1 proto static
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10 metric 1
IwConfig:
eth0 no wireless extensions.
eth1 no wireless extensions.
lono wireless extensions.
Plugins: Shockwave Flash - /usr/lib/flashplugin-installer/libflashplayer.so
PrefSources:
prefs.js
[Profile]/extensions/formhist...@yahoo.com/defaults/preferences/FhcPreferences.js
Profiles: Profile0 (Default) - LastVersion=36.0/20150224134236 (In use)
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/27/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0808
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: M2N
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr0808:bd03/27/2008:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM2N:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1427360/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1411581] [NEW] HP CP4525 printer confused by evince (libcairo 1.13.0~20140204-0ubuntu1) font naming mismatch
Public bug reported: I have an HP Color LaserJet Enterprise CP4525 with firmware 07.164.1, which supports PDF files natively (@PJL LANGUAGE=PDF), and a print server running Debian 7 (cups-filters 1.0.18 and its pdftopdf, and a PDF-enabled PPD). I have been given a PDF file (from pdflatex) that uses four Type 1 font subsets (of four different simple fonts). This file gets printed correctly with /usr/bin/lp . Not so when using evince on Ubuntu trusty: then the printer substitutes a different font (but keeping the glyph widths from the font object in the PDF file, so the letter spacings look all wrong). I've inspected the PDF file evince sends to the printer (which is not identical to the original PDF file: evince rewrites it) and noticed that the value of /FontName in the font program object doesn't match that of /FontName in the font descriptor object; the latter does match /BaseFont in the font object and has the form prescribed in §9.6.4 of the PDF 1.7 specification for font subsets. The /FontName in the font program object, on the other hand, is of the form /CairoFont-N-M, where N and M are integers. If I hand-edit the PDF output by evince, replacing /CairoFont-N-M with the value of /FontName in the corresponding font descriptor object (and adjusting /Length and /Length1 as needed), the result gets printed with the correct fonts. §9.6.2.1 of the PDF 1.7 specification (PDF 32000-1:2008, retrieved from Adobe's web site) does say that [f]or Type 1 fonts, [BaseFont] is always the value of the FontName entry in the font program. One wonders, then, why Cairo changes the name. I could understand it if it wanted to make the font descriptors for two different subsets of the same font share the same font program object; but it doesn't take advantage of this. The sample file I have contains ligatures and accented letters, originally represented in a single font subset by using a non-standard encoding, and evince splits these font subsets into two parts, one of which uses /WinAnsiEncoding; each of the subsets gets its own font program object (with a different value of M in /CairoFont-N-M). So this is not the explanation. I think it would be prudent, in light of HP's PDF interpreter's behaviour, for Cairo to adhere more strictly to the wording of §9.6.2.1 and use the same /FontName in the font program object as in the font descriptor object. I think I'd also like for pdftopdf to incorporate a workaround for this, simply because I have more control over the print server than over the clients. But that's for another (wishlist) bug report. ** Affects: cairo (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1411581 Title: HP CP4525 printer confused by evince (libcairo 1.13.0~20140204-0ubuntu1) font naming mismatch Status in cairo package in Ubuntu: New Bug description: I have an HP Color LaserJet Enterprise CP4525 with firmware 07.164.1, which supports PDF files natively (@PJL LANGUAGE=PDF), and a print server running Debian 7 (cups-filters 1.0.18 and its pdftopdf, and a PDF-enabled PPD). I have been given a PDF file (from pdflatex) that uses four Type 1 font subsets (of four different simple fonts). This file gets printed correctly with /usr/bin/lp . Not so when using evince on Ubuntu trusty: then the printer substitutes a different font (but keeping the glyph widths from the font object in the PDF file, so the letter spacings look all wrong). I've inspected the PDF file evince sends to the printer (which is not identical to the original PDF file: evince rewrites it) and noticed that the value of /FontName in the font program object doesn't match that of /FontName in the font descriptor object; the latter does match /BaseFont in the font object and has the form prescribed in §9.6.4 of the PDF 1.7 specification for font subsets. The /FontName in the font program object, on the other hand, is of the form /CairoFont-N-M, where N and M are integers. If I hand-edit the PDF output by evince, replacing /CairoFont-N-M with the value of /FontName in the corresponding font descriptor object (and adjusting /Length and /Length1 as needed), the result gets printed with the correct fonts. §9.6.2.1 of the PDF 1.7 specification (PDF 32000-1:2008, retrieved from Adobe's web site) does say that [f]or Type 1 fonts, [BaseFont] is always the value of the FontName entry in the font program. One wonders, then, why Cairo changes the name. I could understand it if it wanted to make the font descriptors for two different subsets of the same font share the same font program object; but it doesn't take advantage of this. The sample file I have contains ligatures and accented letters, originally represented in a single font subset by using a non-standard encoding, and evince splits these font subsets
Re: [Desktop-packages] [Bug 1336663] Re: lightdm uses wrong ccache name on pam_krb5 credentials refresh
I'm not aware of any activity on this since Robert Ancell's comment #4 indicating that a proper fix might require extensive refactoring (too extensive for Ubuntu T?). As a workaround I've added an Upstart configuration file to run krenew in every user's session; it's as simple as start on xsession stop on desktop-end respawn exec /usr/bin/krenew -K 60 (One may need to add a -t flag if AFS token renewal is desired.) Lightdm still refreshes the wrong ccache but krenew independently takes care of the right one. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1336663 Title: lightdm uses wrong ccache name on pam_krb5 credentials refresh Status in Light Display Manager: Triaged Status in libpam-krb5 package in Ubuntu: Confirmed Status in lightdm package in Ubuntu: Triaged Bug description: As already noted by Brian Knoll in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/24 lightdm 1.10.1-0ubuntu1 uses an inappropriate credentials cache, /tmp/krb5cc_0, when refreshing Kerberos credentials on screen unlock. I couldn't find the new bug Robert Ancell called for in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/27 so I'm opening one now. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1336663/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1330430] Re: apparmor profile needs review/improvement
Other suffixes are affected besides .pdf. I've just spotted some incidents in my logs involving denied read attempts on .epsi, .ps2 and suffixless application/postscript files. Since .epsi is listed as valid in /etc/mime.types I've now added the following to /etc/apparmor.d/local/usr.bin.evince and verified that it allowed .epsi files to be opened: /**.[eE][pP][sS][fFiI23] rw, However, one could argue that file types can and should be detected based on the file's content, not on its name. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1330430 Title: apparmor profile needs review/improvement Status in “evince” package in Ubuntu: Confirmed Bug description: Apparmor rules for evince forbid opening a PDF from an external drive mounted under /media/… unless its filename ends in '.pdf'. Same file will be opened if it is copied to /home/… or renamed to a filename tailing in '.pdf' on the external drive. See bugs #1096837 and #1327161. On a GNU/Linux system like Ubuntu these rules are useless because filetype is not determined by an extension. Checking the filename adds no security. It smells like snakeoil to me. Please review the apparmor profile. On an GNU/Linux system opening a PDF should not denied on filename. This bug affects Ubuntu versions 14.04 LTS, 12.04 LTS and 10.04 LTS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1330430/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1344810] [NEW] etc/apparmor.d/usr.bin.evince should allow /run/user/*/gvfs-metadata/**
Public bug reported:
/etc/apparmor.d/usr.bin.evince has a line
@{HOME}/.local/share/gvfs-metadata/** l,
However, it is possible (seen on trusty) for session state files to be stored
under /run/user/uid/ instead of ~/.local/share/ . Please consider adding
owner /run/user/*/gvfs-metadata/** l,
to the apparmor profile.
Moreover (but this may be worth discussing and tracking separately) I've
seen evince being denied r access to gvfs-
metadata/home-[[:xdigit:]]+.log . I'm not sure what it needs that access
for, but maybe there is a legitimate need?
** Affects: evince (Ubuntu)
Importance: Undecided
Status: New
** Tags: apparmor
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1344810
Title:
etc/apparmor.d/usr.bin.evince should allow /run/user/*/gvfs-
metadata/**
Status in “evince” package in Ubuntu:
New
Bug description:
/etc/apparmor.d/usr.bin.evince has a line
@{HOME}/.local/share/gvfs-metadata/** l,
However, it is possible (seen on trusty) for session state files to be stored
under /run/user/uid/ instead of ~/.local/share/ . Please consider adding
owner /run/user/*/gvfs-metadata/** l,
to the apparmor profile.
Moreover (but this may be worth discussing and tracking separately)
I've seen evince being denied r access to gvfs-
metadata/home-[[:xdigit:]]+.log . I'm not sure what it needs that
access for, but maybe there is a legitimate need?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1344810/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1336663] Re: lightdm uses wrong ccache name on pam_krb5 credentials refresh
* Robert Ancell [2014-07-08 04:27:34 -]: It's not clear if the problem is the way we are using PAM in LightDM (i.e. insufficient/wrong information for pam-krb5 to do the right thing) or an assumption by pam-krb5 that is not occurring. pam_krb5 needs to be told the name of the credentials cache for the session being unlocked; it can't very well guess it by itself. I believe it looks for the environment variable KRB5CCNAME. This may need to be made a part of the session state as seen by LightDM. pam_krb5 will set this variable (to an unpredictable value) on initial login, so perhaps LightDM should stash its value somewhere at that time; or else it can be retrieved (but is that portable enough?) from /proc/pid/environ for the session's main process. Either way, it needs to be made visible to pam_krb5 at setcred time on unlock. libpam-krb5/cache.c:pamk5_get_krb5ccname() tries pam_getenv() first, then regular getenv(). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1336663 Title: lightdm uses wrong ccache name on pam_krb5 credentials refresh Status in Light Display Manager: Triaged Status in “libpam-krb5” package in Ubuntu: New Status in “lightdm” package in Ubuntu: Triaged Bug description: As already noted by Brian Knoll in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/24 lightdm 1.10.1-0ubuntu1 uses an inappropriate credentials cache, /tmp/krb5cc_0, when refreshing Kerberos credentials on screen unlock. I couldn't find the new bug Robert Ancell called for in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/27 so I'm opening one now. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1336663/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1336663] [NEW] lightdm uses wrong ccache name on pam_krb5 credentials refresh
Public bug reported: As already noted by Brian Knoll in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/24 lightdm 1.10.1-0ubuntu1 uses an inappropriate credentials cache, /tmp/krb5cc_0, when refreshing Kerberos credentials on screen unlock. I couldn't find the new bug Robert Ancell called for in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/27 so I'm opening one now. ** Affects: lightdm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1336663 Title: lightdm uses wrong ccache name on pam_krb5 credentials refresh Status in “lightdm” package in Ubuntu: New Bug description: As already noted by Brian Knoll in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/24 lightdm 1.10.1-0ubuntu1 uses an inappropriate credentials cache, /tmp/krb5cc_0, when refreshing Kerberos credentials on screen unlock. I couldn't find the new bug Robert Ancell called for in https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1296276/comments/27 so I'm opening one now. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1336663/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1330055] [NEW] /usr/bin/psql misinterprets cluster version in ~/.postgresqlrc
Public bug reported: I've just upgraded a client from precise to trusty. As part of that upgrade, postgresql-client-9.1 was uninstalled and replaced with postgresql-client-9.3. This broke the psql client's access to databases that are listed in ~/.postgresqlrc as running version 9.1. If I run psql dbname I now get the following error: Error: /home/username/.postgresqlrc line 2: version 9.1 does not exist The relevant line of /home/username/.postgresqlrc looks like this: 9.1dbhost:5432 dbname This is correct according to the documentation: the postgresqlrc(5) man page describes the VERSION column as The major PostgreSQL version *of the cluster to connect to* (emphasis mine). Note also the comment in /usr/share/postgresql-common/pg_wrapper that says: # for psql we always want the latest version, as this is backwards compatible # to every major version that that we support Unfortunately the flow of control never reaches that point in the code; user_cluster_map() (in PgCommon.pm) calls version_exists(9.1) and throws an error because *on the client* there is only version 9.3. The check is erroneous since it assumes that the client and the server have the same versions of PostgreSQL installed. I could lie to the wrapper and claim that the database cluster runs version 9.3, were it not for the fact that /home/username is on a network share and the same file needs to work for both precise and trusty (and wheezy) clients. This report is about Ubuntu 14.04 LTS, with version 154 of postgresql- client-common. I haven't researched whether any other releases are affected. ** Affects: postgresql-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to postgresql-common in Ubuntu. https://bugs.launchpad.net/bugs/1330055 Title: /usr/bin/psql misinterprets cluster version in ~/.postgresqlrc Status in “postgresql-common” package in Ubuntu: New Bug description: I've just upgraded a client from precise to trusty. As part of that upgrade, postgresql-client-9.1 was uninstalled and replaced with postgresql-client-9.3. This broke the psql client's access to databases that are listed in ~/.postgresqlrc as running version 9.1. If I run psql dbname I now get the following error: Error: /home/username/.postgresqlrc line 2: version 9.1 does not exist The relevant line of /home/username/.postgresqlrc looks like this: 9.1dbhost:5432 dbname This is correct according to the documentation: the postgresqlrc(5) man page describes the VERSION column as The major PostgreSQL version *of the cluster to connect to* (emphasis mine). Note also the comment in /usr/share/postgresql-common/pg_wrapper that says: # for psql we always want the latest version, as this is backwards compatible # to every major version that that we support Unfortunately the flow of control never reaches that point in the code; user_cluster_map() (in PgCommon.pm) calls version_exists(9.1) and throws an error because *on the client* there is only version 9.3. The check is erroneous since it assumes that the client and the server have the same versions of PostgreSQL installed. I could lie to the wrapper and claim that the database cluster runs version 9.3, were it not for the fact that /home/username is on a network share and the same file needs to work for both precise and trusty (and wheezy) clients. This report is about Ubuntu 14.04 LTS, with version 154 of postgresql- client-common. I haven't researched whether any other releases are affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1330055/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1319061] Re: Printing pdf documents from firefox embedded viewer results in empty pages
*** This bug is a duplicate of bug 1315020 *** https://bugs.launchpad.net/bugs/1315020 ** This bug has been marked a duplicate of bug 1315020 PDF.js prints blank pages -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1319061 Title: Printing pdf documents from firefox embedded viewer results in empty pages Status in “firefox” package in Ubuntu: New Bug description: This is on updated 12.04.4 (Precise) 64bit. Not sure exactly since when but it had been working at some point. Testcase: Open a pdf document in Firefox with the browser set to embedded display (so Firefox uses its own viewer). Select print (either the toolbar in the viewer or from the Firefox menu, it did not matter. As a result only empty pages will be produced (tested with a Samsung CLP-325 and a HP LaserJet 1522). Printing does work when using evince. Note: Beside of the now completely failing print there seems to be an additional issue which always produces an additional empty page. IOW same doc has two pages when printing from Firefox but one when printing from evince. The problem seemed to have started with the additional blank page and now ended in all pages being blank. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1319061/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1317394] [NEW] spurious ERROR: [...] has no compat file from emacs-package-install
Public bug reported: Seen in trusty on initial installation of a new-style *-el package: ERROR: package-name is broken - called emacs-package-install as a new-style add-on, but has no compat file. Unpacking package-name (version) ... The package does have a compat file. I believe that the error message is issued because the preinst script runs before the compat file is in place. There is no second error message after the Unpacking line. Also, if I subsequently do an apt-get install --reinstall of that package the error message does not appear at all. This is very minor (the exit 1; line in /usr/lib/emacsen-common/lib.pl is commented out) but may worry some users needlessly. ** Affects: emacsen-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to emacsen-common in Ubuntu. https://bugs.launchpad.net/bugs/1317394 Title: spurious ERROR: [...] has no compat file from emacs-package-install Status in “emacsen-common” package in Ubuntu: New Bug description: Seen in trusty on initial installation of a new-style *-el package: ERROR: package-name is broken - called emacs-package-install as a new-style add-on, but has no compat file. Unpacking package-name (version) ... The package does have a compat file. I believe that the error message is issued because the preinst script runs before the compat file is in place. There is no second error message after the Unpacking line. Also, if I subsequently do an apt-get install --reinstall of that package the error message does not appear at all. This is very minor (the exit 1; line in /usr/lib/emacsen- common/lib.pl is commented out) but may worry some users needlessly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/emacsen-common/+bug/1317394/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1229066] Re: evince-thumbnailer can't run mktexpk
* Sebastien Bacher [2014-01-08 16:57:52 -]: Thanks for your bug report. Could you add an example for such dvi file? I cen try and construct one that reproduces the issue on my system, but there is no guarantee that the same choice of font will reproduce the problem somewhere else: that depends on the history of the individual system (specifically, on whether the pk files for the font in question have already been generated and cached). That would make easier to reproduce/debug the issue With texlive-fonts-extra installed, try the following. If you happen to have used font t2c-iwonami in the past, try with a different font. Note the Permission denied errors when running evince, and the decision to substitute a (very) different font for the one that was requested. $ tex testfont This is TeX, Version 3.1415926 (TeX Live 2009/Debian) (/usr/share/texmf-texlive/tex/plain/base/testfont.tex Name of the font to test = t2c-iwonami Now type a test command (\help for help):) *\table *\bye [1] Output written on testfont.dvi (1 page, 9320 bytes). Transcript written on testfont.log. $ evince testfont.dvi kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 t2c-iwonami /usr/bin/mktexpk: 1: /usr/bin/mktexpk: /usr/share/texmf/web2c/mktexnam: Permission denied mktexpk: / already exists. /usr/bin/mktexpk: 210: /usr/bin/mktexpk: /usr/share/texmf/web2c/mktexupd: Permission denied kpathsea: Appending font creation commands to missfont.log. page: Warning: font `t2c-iwonami' at 600x600 not found, trying `cmr10' instead Running the above resulted in the following dmesg entries: [ 2112.341075] type=1400 audit(1389252767.990:36): apparmor=DENIED operation=exec parent=3320 profile=/usr/bin/evince//sanitized_helper name=/usr/share/texmf/web2c/mktexnam pid=3342 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 [ 2112.475442] type=1400 audit(1389252768.122:37): apparmor=DENIED operation=exec parent=3320 profile=/usr/bin/evince//sanitized_helper name=/usr/share/texmf/web2c/mktexupd pid=3347 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 The problem goes away if one runs the command that was saved in ~/missfont.log and runs evince again on the same .dvi file. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1229066 Title: evince-thumbnailer can't run mktexpk Status in “evince” package in Ubuntu: New Bug description: On Ubuntu 12.04, when running /usr/bin/evince-thumbnailer on a .dvi file that references a font for which there is no PK file on the system yet, AppArmor blocks the execution of /usr/share/texmf/web2c/mktexnam etc. Here are sample audit log messages: [ 5720.378549] type=1400 audit(1379921624.784:28): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexnam pid=6204 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 [ 5720.384833] type=1400 audit(1379921624.788:29): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexupd pid=6209 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 I suspect this is because the sanitized_helper profile in /etc/apparmor.d/abstractions/ubuntu-helpers only covers /bin, /sbin, /usr/bin and /usr/sbin, not /usr/share/texmf/web2c . I'm not sure whether this bug should be filed against apparmor, evince or texlive-binaries; I can think of at least three ways of addressing the issue: 1) add /usr/share/texmf/web2c/* Pixr to the sanitized_helper profile; 2) modify the profile for /usr/bin/evince-thumbnailer to use something other than sanitized_helper; 3) provide a separate AppArmor profile for the /usr/bin/mktexpk wrapper (and its siblings). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1229066/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1229066] [NEW] evince-thumbnailer can't run mktexpk
Public bug reported: On Ubuntu 12.04, when running /usr/bin/evince-thumbnailer on a .dvi file that references a font for which there is no PK file on the system yet, AppArmor blocks the execution of /usr/share/texmf/web2c/mktexnam etc. Here are sample audit log messages: [ 5720.378549] type=1400 audit(1379921624.784:28): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexnam pid=6204 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 [ 5720.384833] type=1400 audit(1379921624.788:29): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexupd pid=6209 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 I suspect this is because the sanitized_helper profile in /etc/apparmor.d/abstractions/ubuntu-helpers only covers /bin, /sbin, /usr/bin and /usr/sbin, not /usr/share/texmf/web2c . I'm not sure whether this bug should be filed against apparmor, evince or texlive-binaries; I can think of at least three ways of addressing the issue: 1) add /usr/share/texmf/web2c/* Pixr to the sanitized_helper profile; 2) modify the profile for /usr/bin/evince-thumbnailer to use something other than sanitized_helper; 3) provide a separate AppArmor profile for the /usr/bin/mktexpk wrapper (and its siblings). ** Affects: evince (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1229066 Title: evince-thumbnailer can't run mktexpk Status in “evince” package in Ubuntu: New Bug description: On Ubuntu 12.04, when running /usr/bin/evince-thumbnailer on a .dvi file that references a font for which there is no PK file on the system yet, AppArmor blocks the execution of /usr/share/texmf/web2c/mktexnam etc. Here are sample audit log messages: [ 5720.378549] type=1400 audit(1379921624.784:28): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexnam pid=6204 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 [ 5720.384833] type=1400 audit(1379921624.788:29): apparmor=DENIED operation=exec parent=6181 profile=/usr/bin/evince-thumbnailer//sanitized_helper name=/usr/share/texmf/web2c/mktexupd pid=6209 comm=mktexpk requested_mask=x denied_mask=x fsuid=1000 ouid=0 I suspect this is because the sanitized_helper profile in /etc/apparmor.d/abstractions/ubuntu-helpers only covers /bin, /sbin, /usr/bin and /usr/sbin, not /usr/share/texmf/web2c . I'm not sure whether this bug should be filed against apparmor, evince or texlive-binaries; I can think of at least three ways of addressing the issue: 1) add /usr/share/texmf/web2c/* Pixr to the sanitized_helper profile; 2) modify the profile for /usr/bin/evince-thumbnailer to use something other than sanitized_helper; 3) provide a separate AppArmor profile for the /usr/bin/mktexpk wrapper (and its siblings). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1229066/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1001035] Re: lightdm uses a hardcoded path to .xsession-errors, please make it configurable
I also find it the current lack of flexibility highly inconvenient.
However, none of the alternatives proposed in the comments above really
cut it as far as I'm concerned. Here is how I'd like to be able to set
up our desktops (users' home directories are on network shares and have
quota imposed on them):
* xsession-errors to a local filesystem, *not* to the home directory;
* automatic log rotation (some users hardly ever log out, there needs to
be a way to keep the log file from growing without bound);
* support for multiple concurrent sessions by the same user, even on the
same computer (e.g., VNC sessions, sessions with different display
depths, etc.; other changes to lightdm may be needed to fully support
this);
* log filtering and compression (to deal with buggy programs that output
the same message in a loop; the latest incident here involved chromium-
browser);
* timestamping of log entries.
Most of this would be easy if there was an option to pipe the output to
an external program (e.g., /usr/bin/logger or some wrapper script around
it). Make that configurable by the administrator and/or the user.
LightDM could pass additional information as command line arguments or
environment variables.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1001035
Title:
lightdm uses a hardcoded path to .xsession-errors, please make it
configurable
Status in Light Display Manager:
Triaged
Status in “lightdm” package in Ubuntu:
Triaged
Bug description:
LightDM uses always $HOME/.xsession-errors as the log file because is
harcoded in xsession.c. But sometimes you want to use a logfile
outside your $HOME, suposse your $HOME is in an SSD and you want to
minimize writes, so you want to put it in /tmp/${USER}_xsession-errors
for example. If you try to make a $HOME/.xsession_errors -
/tmp/{$USER}_xsession-errors symlink to cheat LightDM, then LightDM
will recreate the $HOME/.xsession_errors file and the hack will not
work.
LightDM _always_ recreates $HOME/.xsession_errors and you can't change
it without recompiling. So, I think this log file needs to be
configurable, or at least preserve the symlink if one is present.
Ubuntu 12.04 LTS
LightDM 1.2.1-0ubuntu1
To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1001035/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1146905] [NEW] .doc form cannot be filled in in Writer
Public bug reported: I am given a form (details at end), last edited in 2008 so presumably using Office 2007 or earlier. This form is password-protected against modification of anything but the fields one is meant to type data into. Filling in the form works in Office 2010. With LibreOffice 3.5.7.2 Build ID: 350m1(Build:2) on Ubuntu precise, I cannot fill in any of the fields. Writer says (in the title bar) that the document is read-only. If I View-Toolbars-Form Design and View-Toolbars-Form Navigation I see that almost all the controls are grayed out; the only two exceptions are Open in Design Mode and Automatic Control Focus, however pressing these doesn't result in any noticeable state change. If I press the Edit File button in the Standard toolbar, I get prompted for the document's password (which I don't know). This isn't really a new problem. OpenOffice 3.2 in Ubuntu lucid lets me type a few characters into the first form field, then exactly two characters into the second field before telling me that the form cannot be filled. I'm guessing that the main underlying issue is the same but that another bug (which made OpenOffice 3.2 accept the first few characters of form input) has been fixed. I'm not sure I am at liberty to attach a copy of the .doc file to this document since I don't hold the copyright to it. It can be downloaded from http://formhotel.accessia.se/su/Default.aspx; search for 9031 (other forms on that site may also be affected, I haven't checked) and choose the Word version. ** Affects: libreoffice (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1146905 Title: .doc form cannot be filled in in Writer Status in “libreoffice” package in Ubuntu: New Bug description: I am given a form (details at end), last edited in 2008 so presumably using Office 2007 or earlier. This form is password-protected against modification of anything but the fields one is meant to type data into. Filling in the form works in Office 2010. With LibreOffice 3.5.7.2 Build ID: 350m1(Build:2) on Ubuntu precise, I cannot fill in any of the fields. Writer says (in the title bar) that the document is read-only. If I View-Toolbars-Form Design and View-Toolbars-Form Navigation I see that almost all the controls are grayed out; the only two exceptions are Open in Design Mode and Automatic Control Focus, however pressing these doesn't result in any noticeable state change. If I press the Edit File button in the Standard toolbar, I get prompted for the document's password (which I don't know). This isn't really a new problem. OpenOffice 3.2 in Ubuntu lucid lets me type a few characters into the first form field, then exactly two characters into the second field before telling me that the form cannot be filled. I'm guessing that the main underlying issue is the same but that another bug (which made OpenOffice 3.2 accept the first few characters of form input) has been fixed. I'm not sure I am at liberty to attach a copy of the .doc file to this document since I don't hold the copyright to it. It can be downloaded from http://formhotel.accessia.se/su/Default.aspx; search for 9031 (other forms on that site may also be affected, I haven't checked) and choose the Word version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1146905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1146905] Re: .doc form cannot be filled in in Writer
Reproduced in upstream 3.6.5 on Windows. Upstream bug reports 35159 and 37375 are both possible matches, but since they aren't marked as duplicates I'm not sure which one to link my report to. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1146905 Title: .doc form cannot be filled in in Writer Status in “libreoffice” package in Ubuntu: New Bug description: I am given a form (details at end), last edited in 2008 so presumably using Office 2007 or earlier. This form is password-protected against modification of anything but the fields one is meant to type data into. Filling in the form works in Office 2010. With LibreOffice 3.5.7.2 Build ID: 350m1(Build:2) on Ubuntu precise, I cannot fill in any of the fields. Writer says (in the title bar) that the document is read-only. If I View-Toolbars-Form Design and View-Toolbars-Form Navigation I see that almost all the controls are grayed out; the only two exceptions are Open in Design Mode and Automatic Control Focus, however pressing these doesn't result in any noticeable state change. If I press the Edit File button in the Standard toolbar, I get prompted for the document's password (which I don't know). This isn't really a new problem. OpenOffice 3.2 in Ubuntu lucid lets me type a few characters into the first form field, then exactly two characters into the second field before telling me that the form cannot be filled. I'm guessing that the main underlying issue is the same but that another bug (which made OpenOffice 3.2 accept the first few characters of form input) has been fixed. I'm not sure I am at liberty to attach a copy of the .doc file to this document since I don't hold the copyright to it. It can be downloaded from http://formhotel.accessia.se/su/Default.aspx; search for 9031 (other forms on that site may also be affected, I haven't checked) and choose the Word version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1146905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1146905] Re: .doc form cannot be filled in in Writer
** Description changed: I am given a form (details at end), last edited in 2008 so presumably using Office 2007 or earlier. This form is password-protected against modification of anything but the fields one is meant to type data into. Filling in the form works in Office 2010. With LibreOffice 3.5.7.2 Build ID: 350m1(Build:2) on Ubuntu precise, I cannot fill in any of the fields. Writer says (in the title bar) that the document is read-only. If I View-Toolbars-Form Design and View-Toolbars-Form Navigation I see that almost all the controls are grayed out; the only two exceptions are Open in Design Mode and Automatic Control Focus, however pressing these doesn't result in any noticeable state change. If I press the Edit File button in the Standard toolbar, I get prompted for the document's password (which I don't know). This isn't really a new problem. OpenOffice 3.2 in Ubuntu lucid lets me type a few characters into the first form field, then exactly two characters into the second field before telling me that the form cannot be filled. I'm guessing that the main underlying issue is the same but that another bug (which made OpenOffice 3.2 accept the first few characters of form input) has been fixed. I'm not sure I am at liberty to attach a copy of the .doc file to this - document since I don't hold the copyright to it. It can be downloaded - from http://formhotel.accessia.se/su/Default.aspx; search for 9031 - (other forms on that site may also be affected, I haven't checked) and - choose the Word version. + report since I don't hold the copyright to it. It can be downloaded from + http://formhotel.accessia.se/su/Default.aspx; search for 9031 (other + forms on that site may also be affected, I haven't checked) and choose + the Word version. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1146905 Title: .doc form cannot be filled in in Writer Status in “libreoffice” package in Ubuntu: New Bug description: I am given a form (details at end), last edited in 2008 so presumably using Office 2007 or earlier. This form is password-protected against modification of anything but the fields one is meant to type data into. Filling in the form works in Office 2010. With LibreOffice 3.5.7.2 Build ID: 350m1(Build:2) on Ubuntu precise, I cannot fill in any of the fields. Writer says (in the title bar) that the document is read-only. If I View-Toolbars-Form Design and View-Toolbars-Form Navigation I see that almost all the controls are grayed out; the only two exceptions are Open in Design Mode and Automatic Control Focus, however pressing these doesn't result in any noticeable state change. If I press the Edit File button in the Standard toolbar, I get prompted for the document's password (which I don't know). This isn't really a new problem. OpenOffice 3.2 in Ubuntu lucid lets me type a few characters into the first form field, then exactly two characters into the second field before telling me that the form cannot be filled. I'm guessing that the main underlying issue is the same but that another bug (which made OpenOffice 3.2 accept the first few characters of form input) has been fixed. I'm not sure I am at liberty to attach a copy of the .doc file to this report since I don't hold the copyright to it. It can be downloaded from http://formhotel.accessia.se/su/Default.aspx; search for 9031 (other forms on that site may also be affected, I haven't checked) and choose the Word version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1146905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1020244] [NEW] gvfsd-http loops requesting the same page
Public bug reported: Seen on a lucid system: # pgrep -fl gvfs 2086 /usr/lib/gvfs/gvfsd 2093 /usr/lib/gvfs//gvfs-fuse-daemon /home/CENSORED/.gvfs 2116 /usr/lib/gvfs/gvfs-gdu-volume-monitor 2122 /usr/lib/gvfs/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0 2124 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor 2126 /usr/lib/gvfs/gvfs-afc-volume-monitor 2159 /usr/lib/gvfs/gvfsd-metadata 2175 /usr/lib/gvfs/gvfsd-burn --spawner :1.7 /org/gtk/gvfs/exec_spaw/1 2500 /usr/lib/gvfs/gvfsd-http --spawner :1.7 /org/gtk/gvfs/exec_spaw/2 5282 /usr/lib/gvfs/gvfsd-computer --spawner :1.7 /org/gtk/gvfs/exec_spaw/3 20563 gdb /usr/lib/gvfs/gvfsd-http 2500 Until I attached gvfsd-http with the debugger, it was bombarding a web server with HTTP HEAD requests for the same URL at about 6 seconds' interval. (The web server responded in less than a second.) The requests were all using the same TCP connection, except when the server returned 503 Service Unavailable; then a new TCP connection was established and used. Here is the backtrace from gdb: 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. in ../sysdeps/unix/sysv/linux/poll.c (gdb) bt #0 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7f529fa7f4a9 in ?? () from /lib/libglib-2.0.so.0 #2 0x7f529fa7fc55 in g_main_loop_run () from /lib/libglib-2.0.so.0 #3 0x0040cbce in ?? () #4 0x0040ce5f in ?? () #5 0x7f529f6d8c4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x72d4e2a8) at libc-start.c:226 #6 0x00409299 in ?? () #7 0x72d4e2a8 in ?? () #8 0x001c in ?? () #9 0x0004 in ?? () #10 0x72d4ea83 in ?? () #11 0x72d4ea9c in ?? () #12 0x72d4eaa6 in ?? () #13 0x72d4eaab in ?? () #14 0x in ?? () ** Affects: gvfs (Ubuntu) Importance: Undecided Status: New ** Tags: lucid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1020244 Title: gvfsd-http loops requesting the same page Status in “gvfs” package in Ubuntu: New Bug description: Seen on a lucid system: # pgrep -fl gvfs 2086 /usr/lib/gvfs/gvfsd 2093 /usr/lib/gvfs//gvfs-fuse-daemon /home/CENSORED/.gvfs 2116 /usr/lib/gvfs/gvfs-gdu-volume-monitor 2122 /usr/lib/gvfs/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0 2124 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor 2126 /usr/lib/gvfs/gvfs-afc-volume-monitor 2159 /usr/lib/gvfs/gvfsd-metadata 2175 /usr/lib/gvfs/gvfsd-burn --spawner :1.7 /org/gtk/gvfs/exec_spaw/1 2500 /usr/lib/gvfs/gvfsd-http --spawner :1.7 /org/gtk/gvfs/exec_spaw/2 5282 /usr/lib/gvfs/gvfsd-computer --spawner :1.7 /org/gtk/gvfs/exec_spaw/3 20563 gdb /usr/lib/gvfs/gvfsd-http 2500 Until I attached gvfsd-http with the debugger, it was bombarding a web server with HTTP HEAD requests for the same URL at about 6 seconds' interval. (The web server responded in less than a second.) The requests were all using the same TCP connection, except when the server returned 503 Service Unavailable; then a new TCP connection was established and used. Here is the backtrace from gdb: 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 87../sysdeps/unix/sysv/linux/poll.c: No such file or directory. in ../sysdeps/unix/sysv/linux/poll.c (gdb) bt #0 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7f529fa7f4a9 in ?? () from /lib/libglib-2.0.so.0 #2 0x7f529fa7fc55 in g_main_loop_run () from /lib/libglib-2.0.so.0 #3 0x0040cbce in ?? () #4 0x0040ce5f in ?? () #5 0x7f529f6d8c4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x72d4e2a8) at libc-start.c:226 #6 0x00409299 in ?? () #7 0x72d4e2a8 in ?? () #8 0x001c in ?? () #9 0x0004 in ?? () #10 0x72d4ea83 in ?? () #11 0x72d4ea9c in ?? () #12 0x72d4eaa6 in ?? () #13 0x72d4eaab in ?? () #14 0x in ?? () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1020244/+subscriptions
[Desktop-packages] [Bug 1020244] Re: gvfsd-http loops requesting the same page
** Attachment added: Output of apport-cli -f -p gvfs-backends https://bugs.launchpad.net/bugs/1020244/+attachment/3211178/+files/gvfs.apport -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1020244 Title: gvfsd-http loops requesting the same page Status in “gvfs” package in Ubuntu: New Bug description: Seen on a lucid system: # pgrep -fl gvfs 2086 /usr/lib/gvfs/gvfsd 2093 /usr/lib/gvfs//gvfs-fuse-daemon /home/CENSORED/.gvfs 2116 /usr/lib/gvfs/gvfs-gdu-volume-monitor 2122 /usr/lib/gvfs/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0 2124 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor 2126 /usr/lib/gvfs/gvfs-afc-volume-monitor 2159 /usr/lib/gvfs/gvfsd-metadata 2175 /usr/lib/gvfs/gvfsd-burn --spawner :1.7 /org/gtk/gvfs/exec_spaw/1 2500 /usr/lib/gvfs/gvfsd-http --spawner :1.7 /org/gtk/gvfs/exec_spaw/2 5282 /usr/lib/gvfs/gvfsd-computer --spawner :1.7 /org/gtk/gvfs/exec_spaw/3 20563 gdb /usr/lib/gvfs/gvfsd-http 2500 Until I attached gvfsd-http with the debugger, it was bombarding a web server with HTTP HEAD requests for the same URL at about 6 seconds' interval. (The web server responded in less than a second.) The requests were all using the same TCP connection, except when the server returned 503 Service Unavailable; then a new TCP connection was established and used. Here is the backtrace from gdb: 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 87../sysdeps/unix/sysv/linux/poll.c: No such file or directory. in ../sysdeps/unix/sysv/linux/poll.c (gdb) bt #0 0x7f529f794543 in *__GI___poll (fds=value optimized out, nfds=value optimized out, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7f529fa7f4a9 in ?? () from /lib/libglib-2.0.so.0 #2 0x7f529fa7fc55 in g_main_loop_run () from /lib/libglib-2.0.so.0 #3 0x0040cbce in ?? () #4 0x0040ce5f in ?? () #5 0x7f529f6d8c4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x72d4e2a8) at libc-start.c:226 #6 0x00409299 in ?? () #7 0x72d4e2a8 in ?? () #8 0x001c in ?? () #9 0x0004 in ?? () #10 0x72d4ea83 in ?? () #11 0x72d4ea9c in ?? () #12 0x72d4eaa6 in ?? () #13 0x72d4eaab in ?? () #14 0x in ?? () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1020244/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 807507] Re: apparmor denies evince creating links in .local/share/gvfs-metadata
Also seen on lucid, at least when booted into a 2.6.38 kernel (from
linux-image-generic-lts-backport-natty).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/807507
Title:
apparmor denies evince creating links in .local/share/gvfs-metadata
Status in “evince” package in Ubuntu:
Fix Released
Bug description:
I'm not sure exactly why evince is doing this, but when I open the
attached PDF, I get these messages in my syslog:
[517153.642954] type=1400 audit(1310126279.881:64): apparmor=DENIED
operation=link parent=1 profile=/usr/bin/evince
name=/home/kiko/.local/share/gvfs-metadata/.openRJ3GYV pid=26997
comm=evince requested_mask=l denied_mask=l fsuid=5107 ouid=5107
target=/home/kiko/.local/share/gvfs-metadata/home-1dc5eb46.log
[517153.642147] type=1400 audit(1310126279.881:63): apparmor=DENIED
operation=link parent=1 profile=/usr/bin/evince
name=/home/kiko/.local/share/gvfs-metadata/.openF02GYV pid=26997
comm=evince requested_mask=l denied_mask=l fsuid=5107 ouid=5107
target=/home/kiko/.local/share/gvfs-metadata/home
I have a fix (might be a workaround) here:
--- usr.bin.evince.log2011-07-08 09:44:30.170324154 -0300
+++ usr.bin.evince2011-07-08 09:41:09.807227272 -0300
@@ -52,6 +52,8 @@
@{HOME}/.gnome2/accels/rw,
@{HOME}/.gnome2/accelsevince rw,
@{HOME}/.gnome2/accels/evince rw,
+ @{HOME}/.local/share/gvfs-metadata rw,
+ @{HOME}/.local/share/gvfs-metadata/* rwl,
# from http://live.gnome.org/Evince/SupportedDocumentFormats. Allow
# read and write for all supported file formats
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/807507/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
