Derek, sourcing .profile makes perfect sense. You can't rely on having a
terminal or really being interactive or anything else _anyway_, and in
practice, long experience shows that sourcing profile in Xsession
actually doesn't cause any problems in practice. Display managers should
_always_ source
Public bug reported:
unity_support_test writes to a file called /tmp/unity_support_test.0 no
matter what value is set in TMP, TMPDIR, and so on. This tool should
respect user preferences and not hardcode the temporary directory.
** Affects: nux (Ubuntu)
Importance: Undecided
Status:
apport information
** Attachment added: "IwConfig.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279067/+files/IwConfig.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
apport information
** Attachment added: "ProcEnviron.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279071/+files/ProcEnviron.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
apport information
** Attachment added: "Lsusb.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279069/+files/Lsusb.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
Kern
apport information
** Attachment added: "CurrentDmesg.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279066/+files/CurrentDmesg.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
apport information
** Attachment added: "UdevDb.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279076/+files/UdevDb.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
Ke
apport information
** Attachment added: "CRDA.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279065/+files/CRDA.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
Kernel
apport information
** Attachment added: "UdevLog.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279077/+files/UdevLog.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
apport information
** Attachment added: "WifiSyslog.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279078/+files/WifiSyslog.txt
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, whic
apport information
** Attachment added: "ProcModules.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279073/+files/ProcModules.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
apport information
** Attachment added: "ProcInterrupts.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279072/+files/ProcInterrupts.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/140
apport information
** Attachment added: "ProcCpuinfo.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279070/+files/ProcCpuinfo.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
apport information
** Attachment added: "PulseList.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279074/+files/PulseList.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Titl
apport information
** Attachment added: "RfKill.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279075/+files/RfKill.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
Ke
apport information
** Attachment added: "BootDmesg.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279064/+files/BootDmesg.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Titl
apport information
** Attachment added: "Lspci.txt"
https://bugs.launchpad.net/bugs/1401699/+attachment/4279068/+files/Lspci.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401699
Title:
Kern
apport information
** Tags added: apport-collected
** Description changed:
I have an X1 Carbon Second Generation. With linux-
image-3.16.0-25-generic, everything works fine. With linux-
image-3.16.0-28-generic, if I boot with an external keyboard attached,
the keyboard generates keypress
Public bug reported:
I have an X1 Carbon Second Generation. With linux-
image-3.16.0-25-generic, everything works fine. With linux-
image-3.16.0-28-generic, if I boot with an external keyboard attached,
the keyboard generates keypress events only until I close my laptop lid.
After closing the lid,
Public bug reported:
In Ubuntu 14.10, the Emacs GTK3 scrollbar does not render correctly: it
flickers or fails to update, sometimes randomly. I've spent a bit of
time debugging the problem: with plain X11 and twm, Emacs works just
fine. It's not the graphics driver: if I disable acceleration and r
(Well, at least for ibus >= 1.5.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/493766
Title:
Multi_key / compose does not work when XMODIFIERS="@im=SCIM"
To manage notifications about this bug go
Fixed in Emacs trunk revisions 116858 and 116859.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/493766
Title:
Multi_key / compose does not work when XMODIFIERS="@im=SCIM"
To manage notifications ab
Public bug reported:
The version of ltrace in the distro is ancient and doesn't support PIE
binaries. The upstream version works just fine with them.
Expected:
"ltrace ssh" produces trace of library calls.
Actual:
"ltrace ssh" includes no tracing.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Public bug reported:
While doing some work on the Xorg synaptics driver, I noticed that we
never actually detect palm blocking even after running synclient
PalmDetect=1. Digging in a bit, the driver claims in its capability bits
that it should be sending ABS_TOOL_WIDTH records, but according to
ev
First of all, the program under discussion got it wrong. It shouldn't
have unlinked the destination filename. But the scenario it unwittingly
created is *identical* to the first-time creation of a filename via a
rename, and that's a very important case. EVERY program will encounter
it the first tim
The risk isn't data loss; if you forgo fsync, you accept the risk of
some data loss. The issue that started this whole debate is consistency.
The risk here is of the system ending up in an invalid state with zero-
length files *THAT NEVER APPEARED ON THE RUNNING SYSTEM* suddenly
cropping up. A zer
If you accept that it makes sense to allocate on rename commits for
overwrites of *existing* files, it follows that it makes sense to commit
on *all* renames. Otherwise, users can still see zero-length junk files
when writing a file out for the first time. If an application writes out
a file using
What that code does is stupid, yes. It shouldn't remove the original
unless the platform is win32. *Windows* (except with Transactional NTFS)
doesn't support an atomic rename, so it's no surprise that Python under
Windows doesn't either.
You're seeing a zero-length file because Tso's fix for ext4
@Arial
> No. If I overwrite a file the filesystem MUST guarantee that either
the old version will be there or the new one.
Err, no it's perfectly fine for a filesystem to give you a zero-byte
file if you truncate, then write over the truncated file. Why should the
filesystem try to guess the futu
@Matthew: I reject your premise. ZFS preserves ordering guarantees
between individual writes. UFS maintains a dependency graph of all
pending filesystem operations. Both these filesystems perform rather
well, especially the former.
--
Ext4 data loss
https://bugs.launchpad.net/bugs/317781
You rece
The fundamental problem is that there are two similar but different
operations an application developer can request:
1. open(A)-write(A,data)-close(A)-rename(A,B): replace the contents of B
with data, atomically. I don't care when or even if you make the change,
but whenever you get around to it,
31 matches
Mail list logo
