Hi Colin,
On 3/3/23 19:12, Colin Watson wrote:
> This isn't really analogous to your situation, though. git-dpm is more
> like a workflow tool (such as stgit) than it is like a program you use
> to generate one-off scripted patches. I don't think it would be
> appropriate or reasonable to try to
On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one. Then, my routine for pulling in new upstrea
Hi Branden and Colin!
On 2/27/23 13:56, G. Branden Robinson wrote:
> [added Alex Colomar to CC]
>
> At 2023-02-26T13:30:58+, Colin Watson wrote:
>>> I am not a proficient gbp user, but I think I have done what is
>>> necessary.
>>
>> groff doesn't use gbp - it uses git-dpm.
>
> Right. You t
[added Alex Colomar to CC]
At 2023-02-26T13:30:58+, Colin Watson wrote:
> Sorry about that! Feel free to grab me on IRC if I'm not replying to
> email.
Ah! I'm never on IRC anymore. I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
de
On Sat, Feb 25, 2023 at 11:13:29PM -0600, G. Branden Robinson wrote:
> I've sent you a couple of mails over the past few months, but I don't
> recall seeing a reply.
Sorry about that! Feel free to grab me on IRC if I'm not replying to
email.
> I am not a proficient gbp user, but I think I have d
On Thu, Jul 15, 2021 at 08:08:13AM +0200, Helmut Grohne wrote:
> I also proposed a solution here, which is avoiding
> SystemCallArchitectures=native. Initially, that sounds like a
> maintenance nightmare until you notice that it can be solved on a
> technical level. We already have dh_installsystem
On 16200 March 1977, Michael Lustfield wrote:
I do recall that the FTP masters would've been generally open to have
such an auto-approver (but maybe I'm wrong), but that no-one stepped
up
yet to code it up?
A few of us came up with some proof of concept designs/models, but we
ultimately dropp
On Wed, 14 Jul 2021 18:48:24 +0200
Philipp Kern wrote:
> On 14.07.21 13:47, Michael Biebl wrote:
> > Am 14.07.21 um 12:59 schrieb Simon McVittie:
> I do recall that the FTP masters would've been generally open to have
> such an auto-approver (but maybe I'm wrong), but that no-one stepped up
>
On 16194 March 1977, Simon McVittie wrote:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without ma
Hi Michael,
On Thu, Jul 15, 2021 at 12:22:59AM +0200, Michael Biebl wrote:
> You are right. Thinking more about this, splitting out libsystemd-shared as
> a Multi-Arch: same library will not help with
> SystemCallArchitectures=native, which is used by the services in
> systemd-{container,journal-r
Am 09.07.21 um 14:24 schrieb Helmut Grohne:
Now let's do something stupid. Rename systemd to systemd-core (taking
all files with it, please refrain from discussing the name unless you
seriously consider doing this). Mark it Multi-Arch: allowed. Add a new,
empty binary package systemd. It is Multi
On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote:
> On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> > [a separate libsystemd-shared-249 .deb] would also mean, that on every
> > new upstream release, systemd would have to go through NEW
>
> It seems like we're rejecting a go
On 14.07.21 13:47, Michael Biebl wrote:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex, assign
On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote:
> It seems like this would also be good for src:linux, where ABI breaks
> are often tied to security fixes that should enter the archive ASAP.
As security updates are hand approved, accepting by NEW does not help
that much.
Bastian
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> Asking on #debian-systemd, Marco d'Itri suggested, that we move
> libsystemd-shared into a separate binary package. This would only help, if
> we moved libsystemd-shared into a Multi-Arch location (which means, we'd
> have to carry a
* Simon McVittie [2021-07-14 11:59]:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without manual act
Am 14.07.21 um 13:47 schrieb Michael Biebl:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex, as
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without man
On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> [a separate libsystemd-shared-249 .deb] would also mean, that on every
> new upstream release, systemd would have to go through NEW
It seems like we're rejecting a good technical solution because
social/organisational factors block it (
Helmut Grohne wrote:
> So you made me thinking, can we somehow implement this with our
> current spec? The most important requirements seem to be:
>
> * libsystemd-shared.so and /sbin/systemd need to reside in the same
>binary package.
> * It shall be possible to depend on libsystemd-shared.s
Hi Michael,
Michael Biebl ezt írta (időpont: 2021. júl. 9., P, 22:42):
>
> Hi Guillem,
>
> thanks for your feedback
>
> Am 09.07.21 um 13:46 schrieb Guillem Jover:
> > If the private library has no backwards or forward compatibility (due
> > to the SONAME used) the time window where the library d
Hi Michael,
I'm not yet fully convinced that we're out of options, but let's for a
moment assume we were.
On Fri, Jul 09, 2021 at 10:26:43PM +0200, Michael Biebl wrote:
> So, unless we get a :arch annotation that can be used for M-A:foreign
> packages, maybe the best option is
Given Johannes' re
On Fri, Jul 09, 2021 at 10:28:57AM +0200, Helmut Grohne wrote:
>...
> I also disagree with the need to go through NEW more than once. The new
> package could quite simply be named libsystemd-private and lack a
> .symbols and .shlibs file. Internal users would always use (=
> ${binary:Version}) anyw
> "Helmut" == Helmut Grohne writes:
Helmut> Looks like this leaves us between a rock and a hard
Helmut> place. None of the options seems particularly attractive to
Helmut> me at this point.
We seem to be in a brainstorming space here, throwing out half baked
ideas because none of
Quoting Helmut Grohne (2021-07-09 14:24:01)
> Another possibility (kudos to David Kalnischkies) would be exploiting
> something I might call a loophole in the Multi-Arch spec. While we don't
> currently use arch-qualified dependencies in the archive, the spec considers
> them and dpkg and apt suppo
{+1106+}
systemd-journal-remote (3 binaries)
Installed-Size: [-336-] {+1218+}
systemd-timesyncd (1 binary)
Installed-Size: [-209-] {+595+}
I think the increase in size is significant.
More importantly, I'd need help maintaining this patch going forward
I acknowledge, that option 2 a
* Michael Biebl [2021-07-09 13:24]:
Let me be blunt here: I'm not willing to compromise on robustness here.
Well, I have had my say and ultimately, it's your package and
your decision, of course.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo
Hi Michael,
in your other mail, you gave a very good reason for keeping the systemd
binary and libsystemd-shared.so in the same binary package. That
improves my understanding of why you favour option 3.
On Fri, Jul 09, 2021 at 11:31:15AM +0200, Michael Biebl wrote:
> Am 09.07.21 um 10:28 schrieb
On Fri, 2021-07-09 at 12:29:19 +0200, Michael Biebl wrote:
> Am 09.07.2021 um 11:37 schrieb Timo Röhling:
> > * Michael Biebl [2021-07-09 11:01]:
> > > Splitting out libsystemd-shared (once) will make PID1 very brittle.
> > > It can lead to situations where old systemd + new libsystemd-private
> >
Am 09.07.2021 um 13:01 schrieb Timo Röhling:
* Michael Biebl [2021-07-09 12:29]:
That tightly versioned dependency doesn't help unfortunately. There is
still a time window between the new libsystemd-shared and the new
systemd being unpacked.
There's also a time window between files in /usr/bi
* Michael Biebl [2021-07-09 12:29]:
That tightly versioned dependency doesn't help unfortunately. There is
still a time window between the new libsystemd-shared and the new
systemd being unpacked.
There's also a time window between files in /usr/bin and files in
/usr/lib being replaced.
If yo
Am 09.07.2021 um 11:37 schrieb Timo Röhling:
* Michael Biebl [2021-07-09 11:01]:
Splitting out libsystemd-shared (once) will make PID1 very brittle. It
can lead to situations where old systemd + new libsystemd-private is
installed. If the installation is aborted at this point, you have an
unb
* Michael Biebl [2021-07-09 11:01]:
Splitting out libsystemd-shared (once) will make PID1 very brittle. It
can lead to situations where old systemd + new libsystemd-private is
installed. If the installation is aborted at this point, you have an
unbootable system.
Helmut suggested a tightly ve
Am 09.07.21 um 10:28 schrieb Helmut Grohne:
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
Option 2 would be to drop Multi-Arch: foreign from systemd. This would mean,
that packages like libpam-systemd/libnss-systemd can no longer be installed
for a foreign architecture (even
Am 09.07.21 um 10:28 schrieb Helmut Grohne:
I concur with Marco here and I argue that splitting the library is my
preferred solution. I confirm that you'd need to move the library for
this to work. For the other points I do not follow. I think it would be
ok to move the library using code inside
Hi Michael,
thanks for reaching out!
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> a couple of days ago, the following bug report was filed against systemd
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
Imo, this is bug should be serious. In essence, it is a missin
Hi,
a couple of days ago, the following bug report was filed against systemd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
I'm quoting the relevant parts
I noticed that systemd-machined was failing to start on an arm64
box. This box had armhf enabled, and turns out systemd had been
Hi,
On Thu, Mar 11, 2021 at 12:59:25PM +0530, Manikant Singh wrote:
> Hi Team,
>
> I am IIT Kanpur student. I am trying to build debian package from source
> code after making some changes to it.
> Though I am able to make changes and build debian package successfully,
> some of the changes are n
Hi Team,
I am IIT Kanpur student. I am trying to build debian package from source
code after making some changes to it.
Though I am able to make changes and build debian package successfully,
some of the changes are not reflected.
I made changes to corefile.c which are correctly reflected
But ch
On 2021-01-08, Vagrant Cascadian wrote:
> On 2021-01-08, Vagrant Cascadian wrote:
>> On 2021-01-07, Vagrant Cascadian wrote:
>>> On 2021-01-07, Michael Biebl wrote:
Am 07.01.21 um 18:24 schrieb Michael Biebl:
> as can be seen at [1], systemd does not build reproducibly on armhf and
> a
On Sat, 9 Jan 2021 at 00:52, Michael Biebl wrote:
> Am 07.01.21 um 22:39 schrieb Michael Hudson-Doyle:
>
> > I'm hardly an expert in such things but it looks to me as if gcc is
> > ordering things differently between the two builds:
> >
> >
> https://tests.reproducible-builds.org/debian/dbd/unsta
On 2021-01-08, Vagrant Cascadian wrote:
> On 2021-01-07, Vagrant Cascadian wrote:
>> On 2021-01-07, Michael Biebl wrote:
>>> Am 07.01.21 um 18:24 schrieb Michael Biebl:
as can be seen at [1], systemd does not build reproducibly on armhf and
arm64 (while there is no problem on amd64 and i3
Am 07.01.21 um 22:39 schrieb Michael Hudson-Doyle:
I'm hardly an expert in such things but it looks to me as if gcc is
ordering things differently between the two builds:
https://tests.reproducible-builds.org/debian/dbd/unstable/arm64/systemd_247.2-4.diffoscope.html#systemd-tests_---.---_arm--.
On 2021-01-07, Vagrant Cascadian wrote:
> On 2021-01-07, Michael Biebl wrote:
>> Am 07.01.21 um 18:24 schrieb Michael Biebl:
>>> as can be seen at [1], systemd does not build reproducibly on armhf and
>>> arm64 (while there is no problem on amd64 and i386).
>>>
>>> The problem is, I have no idea w
On 2021-01-07, Michael Biebl wrote:
> Am 07.01.21 um 18:24 schrieb Michael Biebl:
>> as can be seen at [1], systemd does not build reproducibly on armhf and
>> arm64 (while there is no problem on amd64 and i386).
>>
>> The problem is, I have no idea what the diffoscope diff [2] means and
>> how I
On Fri, 8 Jan 2021 at 06:24, Michael Biebl wrote:
> Hi,
>
> as can be seen at [1], systemd does not build reproducibly on armhf and
> arm64 (while there is no problem on amd64 and i386).
>
I'm hardly an expert in such things but it looks to me as if gcc is
ordering things differently between the
[crossposting this to the reproducible-build mailing list. Please CC on
replies, as I'm not subscribed]
Am 07.01.21 um 18:24 schrieb Michael Biebl:
Hi,
as can be seen at [1], systemd does not build reproducibly on armhf and
arm64 (while there is no problem on amd64 and i386).
The problem is,
Hi,
as can be seen at [1], systemd does not build reproducibly on armhf and
arm64 (while there is no problem on amd64 and i386).
The problem is, I have no idea what the diffoscope diff [2] means and
how I can make the package build reproducibly everywhere or how I can
further investigate thi
hardware options. This adds linux kernel command
line options to disable some hardware features.
To complete your installation, please ask for advice on a Kali Linux
user forum.
Kind regards,
Ben.
On 10/01/16 10:07, Patrik Liçi wrote:
Hi debian I have a big problem and I need help immediately
On Sat, 9 Jan 2016 22:07:15 +0100
Patrik Liçi wrote:
> Hi debian I have a big problem and I need help immediately. ... I was
> installing kali linux mini 2.0 in my pc then I power off the pc becouse
> the downloads wants a lot to finish when I want to open my pc it
> c
Hi debian I have a big problem and I need help immediately. ... I was
installing kali linux mini 2.0 in my pc then I power off the pc becouse
the downloads wants a lot to finish when I want to open my pc it
cant .the monitor stays black I tried to install kali linux again
eand
On 27/08/15 09:22, Svante Signell wrote:
> Any ideas how to proceed until bug #795287 is closed?
Hi Svante,
Since you can't install the pre-regression binary (since it links
against the pre-gcc5-transition libs), maybe you'll have more luck
grabbing the old source code and building (older) evolut
On Sat, 2015-08-15 at 12:59 +0200, Adam Borowski wrote:
> On Fri, Aug 14, 2015 at 02:52:14PM +0200, Svante Signell wrote:
> > With the latest debian packages, 3.16.3-1.1 evo cannot any longer
> > connect to Contacts and the gmail account. [...]
> > Following sid has normally been OK, having to acce
On Fri, Aug 14, 2015 at 02:52:14PM +0200, Svante Signell wrote:
> With the latest debian packages, 3.16.3-1.1 evo cannot any longer
> connect to Contacts and the gmail account. [...]
> Following sid has normally been OK, having to accept packages being
> broken but possible to fix rather easily. Ho
On Fri, Aug 14, 2015 at 2:52 PM, Svante Signell wrote:
> There seems to be no easy way to go back to a (working) previous
> version, not even to the stable version if packages in sid and/or
> experimental have been installed. Does a reasonably simple downgrade
> path exist? All ideas are welcomed!
Hi,
With the latest debian packages, 3.16.3-1.1 evo cannot any longer
connect to Contacts and the gmail account:
Failed to connect to 'Contacts'
Cannot find a corresponding account in the org.gnome.OnlineAccounts
service from which to obtain a password for 'a...@gmail.com'
Failed to connect acco
* Sune Vuorela , 2013-07-10, 11:59:
On 2013-07-10, Andreas Beckmann wrote:
osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+
(libgnutls.so.26) + GPLv2 (libpoppler.so.19)
osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+
(libgnutls.so.26) + GPLv2 (libpoppler.so.19
Hi,
On Mittwoch, 10. Juli 2013, Andreas Beckmann wrote:
> I just noticed in my local piuparts instance that adequate now issues
> incompatible-licenses tags, too. Nice feature, Jakub! :-)
adequate 0.7 is now installed on pejacevic.d.o and piu-slave, so from now on,
these results will be shown on
On 2013-07-10, Andreas Beckmann wrote:
> osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
> osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+
> (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
> osgearth: incompatible-li
Hi Andreas,
On Mittwoch, 10. Juli 2013, Andreas Beckmann wrote:
> I just noticed in my local piuparts instance that adequate now issues
> incompatible-licenses tags, too. Nice feature, Jakub! :-)
indeed!
> @Holger: this requires adequate 0.7 - is that running on the slave?
nope, there is only
Hi,
I just noticed in my local piuparts instance that adequate now issues
incompatible-licenses tags, too. Nice feature, Jakub! :-)
Since I'm not too familiar with these issues, i'd like to see that
someone with more experience in that area verifies these problems and
files the corresponding R
Hi Thomas,
On Wed, 10 Mar 2010 08:34:33 +0100, Thomas Weber wrote:
> I'm cc'ing debian-devel, so people see that there is an answer. If
> whoever wants to continue the discussion, please strongly consider
> dropping debian-devel -- the list is noisy enough.
Sorry for additional noise.
> Directl
Hi,
I'm cc'ing debian-devel, so people see that there is an answer. If
whoever wants to continue the discussion, please strongly consider
dropping debian-devel -- the list is noisy enough.
On Wed, Mar 10, 2010 at 12:06:06PM +0900, Atsuhito Kohda wrote:
> Hi all,
>
> I, a maintainer of TeXmacs,
Hi all,
I, a maintainer of TeXmacs, try to make TeXmacs as sane
as possible before squeeze release.
I noticed recently that if one starts Octave plugin under
TeXmacs, it displays an error messages as follows:
-
parse error near line 8 of file
/usr/share/texmacs/TeXmacs/plugins/
Hi all,
On Wed, 10 Feb 2010 21:55:07 -0600, Dirk Eddelbuettel wrote:
> Beauty of different timezones :) Atsuhito had already sent me the file when
> I got up this morning.
>
> There were two issues: a) the file was really two files with the \eof marker
> denoting the end [ but R doesn't have a
On 10 February 2010 at 22:26, Asheesh Laroia wrote:
| yOn Tue, 9 Feb 2010, Dirk Eddelbuettel wrote:
|
| > Asheesh Laroia asheesh.org> writes:
| >> On Tue, 9 Feb 2010, Atsuhito Kohda wrote:
| >>> I, a maintainer of TeXmacs, have got an FTBFS bug#551254
| >>> http://bugs.debian.org/cgi-bin/bugrepo
On Wed, 10 Feb 2010, Dirk Eddelbuettel wrote:
On 10 February 2010 at 22:26, Asheesh Laroia wrote:
| yOn Tue, 9 Feb 2010, Dirk Eddelbuettel wrote:
|
| > Asheesh Laroia asheesh.org> writes:
| >> On Tue, 9 Feb 2010, Atsuhito Kohda wrote:
| >>> I, a maintainer of TeXmacs, have got an FTBFS bug#551
yOn Tue, 9 Feb 2010, Dirk Eddelbuettel wrote:
Asheesh Laroia asheesh.org> writes:
On Tue, 9 Feb 2010, Atsuhito Kohda wrote:
I, a maintainer of TeXmacs, have got an FTBFS bug#551254
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551254
I temporarily remove a problematic patch but clearly it
Asheesh Laroia asheesh.org> writes:
> On Tue, 9 Feb 2010, Atsuhito Kohda wrote:
> > I, a maintainer of TeXmacs, have got an FTBFS bug#551254
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551254
> >
> > I temporarily remove a problematic patch but clearly it is
> > not a real fix. A plugin
On Tue, 9 Feb 2010, Atsuhito Kohda wrote:
Hi all,
I, a maintainer of TeXmacs, have got an FTBFS bug#551254
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551254
I temporarily remove a problematic patch but clearly it is
not a real fix. A plugin of R seems not to work anymore.
CC:ing Mako
Hi all,
I, a maintainer of TeXmacs, have got an FTBFS bug#551254
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551254
I temporarily remove a problematic patch but clearly it is
not a real fix. A plugin of R seems not to work anymore.
I don't know R language at all so request a help of R lan
[please don't top-post]
On Tue, Dec 22, 2009 at 02:31:16PM +0700, Muhammad H Hilman wrote:
> Wow, it's work
>
> but, must I change the code on my application that needed filelock?
> because, filelock code on that application stated as ubuntu command (just
> filelock)
> as far as I know debian com
Wow, it's work
but, must I change the code on my application that needed filelock?
because, filelock code on that application stated as ubuntu command (just
filelock)
as far as I know debian command on filelock is (filelock-create)
can you tel me what's the different between (filelock-create) com
On Thu, Dec 17, 2009 at 11:16:02PM +0100, Michelle Konzack wrote:
> maybe
> apt-get install liblockfile1
Possibly, but lockf() and fcntl() are usually better, and are present
in libc.
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `'
Hello,
maybe
apt-get install liblockfile1
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Lin
[Please note that this question is more appropriate for debian-user, not
debian-devel.]
On Thu, Dec 17, 2009 at 10:51:39AM +0700, Muhammad H Hilman wrote:
> Dear Debian developers
> I run DOVIS 2.0 (docking application) in cluster server using Debian Sarge
> Then I got *"Can not get init lock!"*
Dear Debian developers
I run DOVIS 2.0 (docking application) in cluster server using Debian Sarge
Then I got *"Can not get init lock!"* notification
here is the screenshoot
[image: http://img710.imageshack.us/img710/7643/35869453.png]
I already asked the developers about this problem
They said
Thanks for the help, guys! I have lots of pointers now to go from. -
Lex
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I replied to him in private (because I wanted to mention his current
emailForward setting).
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Who would I talk to about machine access issues?
I suspect my l...@debian.org alias is pointing to an old college email.
I tried to check it by logging into people.debian.org, but I was
refused access. Now I'm stuck. What should I try next, or
who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sean finney a écrit :
> hiya,
>
> On Wednesday 20 August 2008 03:40:41 pm Laurent Guignard wrote:
>> I just began to build a package. I read some tutorial and I have a small
>> question :
>
> in addition to the other suggestions, it should be pointed
hiya,
On Wednesday 20 August 2008 03:40:41 pm Laurent Guignard wrote:
> I just began to build a package. I read some tutorial and I have a small
> question :
in addition to the other suggestions, it should be pointed out that a more
appropriate (and possibly more helpful) mailing list for this t
On Wed, Aug 20, 2008 at 03:40:41PM +0200, Laurent Guignard wrote:
> How to update configuration files stored in local users home directory
> with these contained in package and save the previous configuration
> files somewhere in the filesystem hierarchy ?
You don't do that at all. The contents o
On Wed, 2008-08-20 at 15:40 +0200, Laurent Guignard wrote:
> I just began to build a package. I read some tutorial and I have a small
> question :
> How to update configuration files stored in local users home directory
Generally, packages don't do that - it is up to the runtime program to
handle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I just began to build a package. I read some tutorial and I have a small
question :
How to update configuration files stored in local users home directory
with these contained in package and save the previous configuration
files somewhere in th
On Tue, Apr 10, 2007 at 11:47:33AM -0700, Steve Langasek wrote:
> No, it wasn't; it was reported against a version of mysql that was only in
> sid.
>
> Now if there's a reason to believe it also applies to the etch version of
> the package, then ok; but that's not the version it was filed against.
On Tue, Apr 10, 2007 at 10:39:10AM +0200, Christian Hammers wrote:
> On 2007-04-09 Steve Langasek wrote:
> > On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > > > Mmm, guess I wasn't clear -- I mean that there's no point in trying to
> > > > work
> > > > on this bug, because
On 2007-04-09 Steve Langasek wrote:
> On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > > Mmm, guess I wasn't clear -- I mean that there's no point in trying to
> > > work
> > > on this bug, because lenny *as a whole* will not support 2.4 kernels.
> > > (the
> > > glibc ma
On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > Mmm, guess I wasn't clear -- I mean that there's no point in trying to work
> > on this bug, because lenny *as a whole* will not support 2.4 kernels. (the
> > glibc maintainers are eager to drop LinuxThreads support, which mean
On 2007-04-09 Lennart Sorensen wrote:
> On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> > What I feared was the upgrade process itself. I guess that mysql and the
> > new 2.6 kernel will get installed in the same "apt-get dist-upgrade" run
> > and thus if mysql-server-5.0 han
On Mon, Apr 09, 2007 at 01:28:18PM +0200, Christian Hammers wrote:
> What I feared was the upgrade process itself. I guess that mysql and the
> new 2.6 kernel will get installed in the same "apt-get dist-upgrade" run
> and thus if mysql-server-5.0 hangs and the user presses ctrl-c he is left
> with
On 2007-04-07 Steve Langasek wrote:
> On Sat, Apr 07, 2007 at 03:39:11PM -0400, Lennart Sorensen wrote:
> > On Sat, Apr 07, 2007 at 12:28:13PM -0700, Steve Langasek wrote:
> > > Isn't this only reported against the version in sid, which is not
> > > included in etch?
>
> > > Etch is the last Deb
On Sun, Apr 08, 2007 at 02:44:33AM +0200, Jose Carlos Garcia Sogo wrote:
> El sáb, 07-04-2007 a las 12:54 -0700, Steve Langasek escribió:
> > On Sat, Apr 07, 2007 at 03:39:11PM -0400, Lennart Sorensen wrote:
> > > On Sat, Apr 07, 2007 at 12:28:13PM -0700, Steve Langasek wrote:
> > > > Isn't this on
El sáb, 07-04-2007 a las 12:54 -0700, Steve Langasek escribió:
> On Sat, Apr 07, 2007 at 03:39:11PM -0400, Lennart Sorensen wrote:
> > On Sat, Apr 07, 2007 at 12:28:13PM -0700, Steve Langasek wrote:
> > > Isn't this only reported against the version in sid, which is not included
> > > in etch?
>
>
On Sat, Apr 07, 2007 at 03:39:11PM -0400, Lennart Sorensen wrote:
> On Sat, Apr 07, 2007 at 12:28:13PM -0700, Steve Langasek wrote:
> > Isn't this only reported against the version in sid, which is not included
> > in etch?
> > Etch is the last Debian release that supports upgrades from 2.4 kernel
On Sat, Apr 07, 2007 at 12:28:13PM -0700, Steve Langasek wrote:
> Isn't this only reported against the version in sid, which is not included
> in etch?
>
> Etch is the last Debian release that supports upgrades from 2.4 kernels.
> Lenny will not run on a 2.4 kernel. Perhaps the users should just
On Sat, Apr 07, 2007 at 04:06:32PM +0200, Christian Hammers wrote:
> Two users reported that a sarge->etch upgrade with a running 2.4 kernel
> does not work because /usr/sbin/mysqld from the mysql-server-5.0 package
> hangs and postinst never finishes.
> I've just tried to reproduce it myself but
On Sat, Apr 07, 2007 at 04:06:32PM +0200, Christian Hammers wrote:
> Two users reported that a sarge->etch upgrade with a running 2.4 kernel
> does not work because /usr/sbin/mysqld from the mysql-server-5.0 package
> hangs and postinst never finishes.
>
> I've just tried to reproduce it myself bu
Hello
Two users reported that a sarge->etch upgrade with a running 2.4 kernel
does not work because /usr/sbin/mysqld from the mysql-server-5.0 package
hangs and postinst never finishes.
I've just tried to reproduce it myself but kernel 2.4 dislikes my SATA
controller and I cannot get it to boot.
On Mon, 18 Dec 2006, John Goerzen wrote:
On Mon, Dec 18, 2006 at 10:55:48AM -0600, Carlo Segre wrote:
On Mon, 18 Dec 2006, John Goerzen wrote:
Hi,
#396817 was reported back in November. Ian Lynagh, maintainer of GHC,
and I both believe that the build was proceeding normally and that on
the
1 - 100 of 169 matches
Mail list logo
