, including an RC bug that blocked it for at least
stretch. Could we please remove this package?
oldtechaa
[1] https://web.archive.org/web/20100213005937/http://www.pantor
.com/download.html
.
In the meantime, here's a patch that adds the package Suggests.
oldtechaa
On Mon, Feb 26, 2018 at 8:42 AM, intrigeri <intrig...@debian.org> wrote:
> oldtechaa:
> > So the options are generally either keep it in $PATH and add docs or move
> > it to /usr/share/doc/?
>
> Yes.
>
Here's a patch for debian/control that should fix this. It seems like it
could be made clearer. If you have any thoughts on this, I can change it.
oldtechaa
On Mon, Feb 26, 2018 at 11:55 AM, oldtechaa <oldtec...@gmail.com> wrote:
> OK. I'll work on it.
>
> oldtechaa
>
> On
OK. I'll work on it.
oldtechaa
On Feb 26, 2018 9:26 AM, "intrigeri" <intrig...@debian.org> wrote:
> oldtechaa:
> > Do you want it in both the package description and README.debian?
>
> One of those is sufficient (and duplicated info would inevitably end
> up de-synchronized).
>
Do you want it in both the package description and README.debian?
oldtechaa
On Feb 26, 2018 8:43 AM, "intrigeri" <intrig...@debian.org> wrote:
> oldtechaa:
> > Just out of curiosity, would the package description be a bad place to
> put
> > documentati
Just out of curiosity, would the package description be a bad place to put
documentation on dependencies for perli11ndoc? I personally practically
never read README.debian but look at the package description.
oldtechaa
On Feb 25, 2018 2:44 PM, "oldtechaa" <oldtec...@gmail.com&g
be willing to wait? I might not be able to get to it
right away.
oldtechaa
On Feb 26, 2018 4:48 AM, "intrigeri" <intrig...@debian.org> wrote:
> Hi,
>
> > oldtechaa:
> > I see what you mean. I think a suggestion would still be good.
>
> > As for i
Package: libglib-object-introspection-perl
Version: 0.042-1
Severity: normal
Dear Maintainer,
Utility perli11ndoc requires the *.gir files for introspected libraries to be
installed to view documentation. I can't find anywhere in the documentation for
this package that notes that the .gir
Package: libglib-object-introspection-perl
Version: 0.042-1
Severity: normal
Dear Maintainer,
The utility perli11ndoc in libglib-object-introspection-perl depends on
libxml-libxml-perl. This should be either a package dependency or
recommendation for those who intend to use perli11ndoc.
--
Will we be seeing this in the next Jessie point release?
I believe this bug may have come about due to operator error. I may have
been uncommenting the lines
# autologin-user = User ..
# autologin-user-timeout = ..
Due to the fact that these lines are not after the [SeatDefaults] line,
they were not being accepted. I'll close this bug.
I learned that Padre has been removed from Debian in newer releases, so I
would suppose this plugin will be also soon. You can disregard this bug.
I guess you can disregard this bug, because I just learned that Padre has
been removed from Debian in newer releases.
It was discovered that Padre does ask for a Git password, but only if you
use a terminal to run Padre. However, this should not be required, and a
method of entering it even when using a launcher for Padre should be
included.
Entering a password in the terminal also hangs all processing of your Git
request.
On Thu, Feb 25, 2016 at 11:12 PM, oldtechaa <oldtec...@gmail.com> wrote:
> It was discovered that Padre does ask for a Git password, but only if you
> use a terminal to run Padre. However,
Package: libpadre-plugin-git-perl
Version: 0.12-1
Severity: important
Dear Maintainer,
In an attempt to push changes to origin on Padre's Git plugin, the plugin
responds with an error dialog containing the following:
"fatal: could not read Password for 'https://oldtec...@bitbucket.org': No such
Package: libpadre-plugin-git-perl
Version: 0.12-1
Severity: minor
Dear Maintainer,
Using the Padre Git plugin, an attempt to stage all or stage a particular file
results in an information dialog "Info: There is no response, just as if you
had run it on the cmd yourself." The stage then succeeds,
The original laptop that was working has now, on a separate install of 8.3
with the 304xx nVidia driver installed from the repositories, stopped
logging in automatically.
I see you already filed one; never mind.
On Sun, Jan 31, 2016 at 7:21 PM, oldtechaa <oldtec...@gmail.com> wrote:
> So should I file an RM: bug instead to remove it from all suites?
>
>
> On Sun, Jan 31, 2016 at 7:12 PM, Daniel Schepler <dschep...@gmail.com>
> wrote
So should I file an RM: bug instead to remove it from all suites?
On Sun, Jan 31, 2016 at 7:12 PM, Daniel Schepler <dschep...@gmail.com>
wrote:
> On Sun, Jan 31, 2016 at 11:06 AM, oldtechaa <oldtec...@gmail.com> wrote:
> > The package should be autoremoved by an RC bug, c
The package should be autoremoved by an RC bug, correct?
Package: minetest-mod-pipeworks
Version: 0~20130827+git59362e3d20-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
The pipeworks mod for minetest has a bug which makes it impossible to create
pumps, and possibly other crafts in the mod.
The pump recipe contains "moreores:copper_ingot",
Package: tads2-mode
Severity: serious
Justification: Policy 7.7
Dear Maintainer,
tads2-mode violates Section 7.7 of the Debian Policy Manual, which states that
packages must include dependencies for the clean rule in Build-Depends rather
than Build-Depends-Indep.
This package has a number of
Package: src:linux
Version: 4.3.3-7~bpo8+1
Followup-For: Bug #808479
Dear Maintainer,
I can also confirm this bug on an Inspiron 530 w/ 2GB RAM. On this computer, it
takes about 15hrs. to crash the computer. The memory usage climbs up to that
point, not due to any usage on the part of
This bug might also be good to have marked important, as it makes the
kernel nearly unusable in some cases, and it is a fairly big bug. I also
would say it is probably upstream, although that can't be said for certain
at this point, I don't think.
On Sun, Jan 24, 2016 at 9:41 PM, oldtechaa
The problem has returned on a computer with exactly the same purpose, this
time a Dell Inspiron 530.
On Jan 19, 2016 8:02 AM, "oldtechaa" <oldtec...@gmail.com> wrote:
> The bug might be hardware related, as one of the desktops was replaced and
> the problem went awa
Package: src:linux
Version: 4.3.3-5
Severity: important
Tags: upstream
Dear Maintainer,
We have tried several different kernels on this Dell Optiplex 320. The USB
chipset is an AMD SB600, which was previously known by developers to have
freeze issues when multiple devices were plugged in. We are
The bug might be hardware related, as one of the desktops was replaced and
the problem went away. The new replacement is an Optiplex 320, and since it
is used for the same purpose, it has a virtually identical set of packages.
Again, there may be minor differences, but they should only be in the
I forgot to mention that the debug logs are with "drm.debug=0x04" enabled
on the kernel command line.
Package: src:linux
Version: 3.16.7-ckt11-1+deb8u3
Severity: important
Dear Maintainer,
Using the nouveau kernel driver always results in a black screen upon
framebuffer handover approx. 15 seconds into boot. The hardware is a GeForce Go
6100 with an MCP61 southbridge on a Gateway MT3419 laptop.
Package: xfce4-sensors-plugin
Version: 1.2.5-2
Severity: normal
Dear Maintainer,
The xfce sensors plugin crashes and leaves the panel when hard disk monitoring
is enabled on Jessie. In order to use hard disk monitoring, I obviously had to
setuid hddtemp. I know the setuid hddtemp issue has been
ServerArgsLocal=-br -nolisten tcp
AllowNullPasswd=true
AllowShutdown=All
[X-:*-Greeter]
PreselectUser=Previous
FocusPasswd=true
LoginMode=DefaultLocal
AllowClose=true
[X-:0-Core]
AutoLoginUser=oldtechaa
ClientLogFile=.xsession-errors
[X-:0-Greeter]
-- debconf information:
* shared/default-x-display
[lightdm-greeter] 1.8.5-2
Versions of packages lightdm recommends:
ii xserver-xorg 1:7.7+7
Versions of packages lightdm suggests:
ii accountsservice 0.6.37-3+b1
ii upower 0.99.1-3.2
-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
autologin-user = oldtechaa
33 matches
Mail list logo
