* [PATCHv3] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-14 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110213211855.GC13279@pengutronix.de>
On Sun, 13 Feb 2011 22:18:55 +0100
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> Maybe Sascha can fix this up when taking the patch? (Assuming the
> others are happy now, too of course.)
That would be great, because I'll be travelling tommorow and won't be
able to modify the patch soon.
>
> And I wonder there is no copyright statement by you in
> arch/arm/mach-mx3/mach-bug.c, maybe because you consider your changes
> too minor to be relevant? (INAL and I don't know who to value your
> contribution.)
yes,that's what I tought...I'd be happy to have my name in the
copyrights,however I'm not sure the contribution is relevant
enough...still it was quite some work for
me (rebasing,debugging,upstrem ajustements).
There was a thread about that with the nexus one support from Daniel
Walker in the msm mailing list...I don't have it off hand because I'm
on a mobile device.
Thanks a lot for the review!!!
Denis
^ permalink raw reply
* [Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
From: bugzilla-daemon @ 2011-02-14 1:05 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-26552-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=26552
--- Comment #55 from Helber Maciel Guerra <helbermg@gmail.com> 2011-02-14 01:05:44 ---
OK, it works.
kernel(git), xf86-video-ati (git), libdrm (git),xorg-x11-server-Xorg.x86_64
(1.9.3-4.fc14)
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc M880G [Mobility
Radeon HD 4200] [1002:9712]
Tanks a lot, Helber Maciel Guerra.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
^ permalink raw reply
* Re: MRST SPI
From: Feng Tang @ 2011-02-14 1:05 UTC (permalink / raw)
To: Tom
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
alan-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <AANLkTin60qjesNcaPRiDftt8s83i7JTRkB7zbt1pW31--JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Tom,
On Thu, 10 Feb 2011 18:48:00 +0800
Tom <tom.spi.devel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi All,
>
> I have a SPI device problem on MRST CDK.
>
> I use a GPIO as SS because my slave device expects the SS to be low
> between byte transfers.
The DW spi controller has a slave select register for that purpose, and
myself don't have experience of using an external GPIO lines for SS, so
no comment here.
> My probe function does a read as:
>
> int read_val;
> -------
> ---
> read_val = spi_w8r8(&spi_dev,0x20);
> if ( read_val < 0 )
> printk ( "spi_read err\n");
> else
> printk ( "spi_read %d\n",read_val );
> ----
> --
>
> The MRST SFI interface passes the device board info. Because, my
> device is not listed in the IA32 f/w I modified the MRST.c code
> sfi_handle_spi_dev function as:
>
> while(dev->name[0])
> {
> if (dev->type == SFI_DEV_TYPE_SPI &&
> !strncmp(dev->name,
> spi_info->modalias, 16)) {
> if (!strncmp("spi_old_device",
> spi_info->modalias, 16)){
> strncpy (spi_info->modalias,
> "spi_my_dev",16);
> pdata =
> dev->get_platform_data(spi_info); pr_info ( "spi_old_device modalias
> to spi_my_dev ");
> }
> else
> {
> pdata = dev->get_platform_data(spi_info);
> }
> break;
> }
> dev++;
> }
>
> i also modified the devs_id array to change the platform_data
>
> {"spi_old_dev", SFI_DEV_TYPE_SPI, 0, &no_platform_data}
>
> The issue is that for the spi_w8r8 call, i get multiple read
> (multiple * (8 clock cycles/SS toggle))on the SPI bus.
>
> Also regarding the spi->irq, is it the responsibility of the protocol
> driver to register for this irq and handle it or does the spi
> framework or master driver take care of this ?
>
> Any pointers would be really helpful. ( attached is the test code)
Suggest you refer the arch/platform/mrst/mrst.c about setting up
the max3110 spi device's platform and controller data, you can
find it in Alan Cox's MID reference tree:
git://git.kernel.org/pub/scm/linux/kernel/git/alan/linux-2.6-mid-ref.git
Thanks,
Feng
>
> Regards,
> Tom
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
^ permalink raw reply
* Re: Regression - Xorg start failed
From: James Morris @ 2011-02-14 1:04 UTC (permalink / raw)
To: Chris Wright
Cc: Linus Torvalds, Dave Airlie, Dave Young, linux-kernel,
David Airlie, dri-devel
In-Reply-To: <20110214003531.GH9869@sequoia.sous-sol.org>
On Sun, 13 Feb 2011, Chris Wright wrote:
> Subject: [PATCH] pci: use security_capable correctly during config space read
>
> Commit 47970b1 ("pci: use security_capable() when checking capablities
> during config space read") is just plain broken. The normal capable()
> interface returns true on success, but the LSM interface returns 0 on
> success.
>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Sorry, I should have caught this.
Acked-by: James Morris <jmorris@namei.org>
> ---
>
> I've tested this quickly (lspci behaviour is as expected).
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index f7771f3..ea25e5b 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -369,7 +369,7 @@ pci_read_config(struct file *filp, struct kobject *kobj,
> u8 *data = (u8*) buf;
>
> /* Several chips lock up trying to read undefined config space */
> - if (security_capable(filp->f_cred, CAP_SYS_ADMIN)) {
> + if (security_capable(filp->f_cred, CAP_SYS_ADMIN) == 0) {
> size = dev->cfg_size;
> } else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
> size = 128;
>
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* RE: x86 HPET MSI IRQs vs resume from S3
From: Wei, Gang @ 2011-02-14 1:00 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xensource.com; +Cc: Wei, Gang
In-Reply-To: <4D42992E020000780002F1E4@vpn.id2.novell.com>
Jan Beulich wrote on 2011-01-28:
> Going through hpet_broadcast_init(), I see that hpet_setup_msi_irq()
> gets called during resume, thus causing setup_irq() to be called. I'm
> failing to spot the corresponding release_irq(), and hence I can't see
> how this whole code path is supposed to work during resume (other than
> always falling back to using legacy_hpet_event). Instead I'm wondering
> whether in the resume case only msi_compose_msg()/
> hpet_msi_write() should be called for each IRQ used rather than the
> whole hpet_broadcast_init().
I do think below patch could resolve this issue well. Didn't create a new path for hpet broadcast init while resume because there exists many condition checks in existing path.
diff -r 67f2fed57034 xen/arch/x86/hpet.c
--- a/xen/arch/x86/hpet.c Fri Feb 11 18:22:37 2011 +0000
+++ b/xen/arch/x86/hpet.c Tue Feb 15 14:48:54 2011 +0800
@@ -367,12 +367,20 @@ static int hpet_setup_msi_irq(unsigned i
int ret;
struct msi_msg msg;
struct hpet_event_channel *ch = &hpet_events[irq_to_channel(irq)];
-
- irq_desc[irq].handler = &hpet_msi_type;
- ret = request_irq(irq, hpet_interrupt_handler,
- 0, "HPET", ch);
- if ( ret < 0 )
- return ret;
+ irq_desc_t *desc = irq_to_desc(irq);
+
+ if ( desc->handler == &no_irq_type )
+ {
+ desc->handler = &hpet_msi_type;
+ ret = request_irq(irq, hpet_interrupt_handler,
+ 0, "HPET", ch);
+ if ( ret < 0 )
+ return ret;
+ }
+ else if ( desc->handler != &hpet_msi_type )
+ {
+ return -EINVAL;
+ }
msi_compose_msg(NULL, irq, &msg);
hpet_msi_write(irq, &msg);
Jimmy
^ permalink raw reply
* Re: [PATCH] stmmac: enable wol via magic frame by default.
From: David Miller @ 2011-02-14 1:00 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1297414306-11271-1-git-send-email-peppe.cavallaro@st.com>
From: Peppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 11 Feb 2011 09:51:46 +0100
> This patch enables it by default when the driver starts.
> This has been required by many people and seems to actually be
> useful on STB.
> At any rate, the WoL modes can be selected and turned-on/off
> by using the ethtool at run-time by users.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [patch net-next-2.6 4/4] bridge: implement [add/del]_slave ops
From: David Miller @ 2011-02-14 0:59 UTC (permalink / raw)
To: jpirko; +Cc: netdev, shemminger, kaber, fubar, eric.dumazet, nicolas.2p.debian
In-Reply-To: <20110213193341.GG2740@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sun, 13 Feb 2011 20:33:42 +0100
> add possibility to addif/delif via rtnetlink
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [patch net-next-2.6 3/4] bond: implement [add/del]_slave ops
From: David Miller @ 2011-02-14 0:58 UTC (permalink / raw)
To: jpirko; +Cc: netdev, shemminger, kaber, fubar, eric.dumazet, nicolas.2p.debian
In-Reply-To: <20110213193300.GF2740@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sun, 13 Feb 2011 20:33:01 +0100
> allow enslaving/releasing using netlink interface
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [patch net-next-2.6 1/4] rtnetlink: implement setting of master device
From: David Miller @ 2011-02-14 0:58 UTC (permalink / raw)
To: kaber; +Cc: jpirko, netdev, shemminger, fubar, eric.dumazet,
nicolas.2p.debian
In-Reply-To: <4D583C2F.7070308@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 13 Feb 2011 21:16:47 +0100
> Am 13.02.2011 21:15, schrieb Jiri Pirko:
>> Subject: [patch net-next-2.6 1/4] rtnetlink: implement setting of master device
>>
>> This patch allows userspace to enslave/release slave devices via netlink
>> interface using IFLA_MASTER. This introduces generic way to add/remove
>> underling devices.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] wpa-supplicant: change dbus interface
From: Xu, Dongxiao @ 2011-02-14 0:55 UTC (permalink / raw)
To: Stefan Schmidt, poky@yoctoproject.org
In-Reply-To: <20110211100751.GF9652@excalibur.local>
Hi Stefan,
Stefan Schmidt wrote:
> Hello.
>
> On Fri, 2011-02-11 at 17:11, Dongxiao Xu wrote:
>> From: Dongxiao Xu <dongxiao.xu@intel.com>
>>
>> # Driver interface for FreeBSD net80211 layer (e.g., Atheros driver)
>> #CONFIG_DRIVER_BSD=y @@ -404,4 +405,4 @@ CONFIG_PEERKEY=y #LIBS_c +=
>> -lbfd -liberty -lz CONFIG_TLS = gnutls CONFIG_GNUTLS_EXTRA=y
>> -CONFIG_CTRL_IFACE_DBUS=y
>> +CONFIG_CTRL_IFACE_DBUS_NEW=y
>
> Any reason not enable both dbus interfaces? They can happily life
> next to each other. Thats how I did it in OE.
It is OK for me to enable both options. I will change it in my next pull request.
>
>> diff --git
>> a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc
>> b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc
>> index 7865b8f..cd62d8f 100644
>> --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc
>> +++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc
>> @@ -6,7 +6,7 @@ LICENSE = "GPLv2 | BSD"
>> LIC_FILES_CHKSUM =
>>
>>
>> "file://../COPYING;md5=c54ce9345727175ff66d17b67ff51f58 \
>> file://../README;md5=54cfc88015d3ce83f7156e63c6bb1738 \
>> file://wpa_supplicant.c;beginline=1;endline=17;md5=acdc5a4b0d6345f21f136eace747260e"
>> -DEPENDS = "gnutls dbus" +DEPENDS = "gnutls dbus libnl"
>
> Hmm, does poky onl yhave libnl2 recipes or both libnl and libnl2?
>
> If the later you should depend on libnl2 instead. I'm trying to get
> rid of these libnl mess in OE and getting all packges over to libnl2.
> Would be great if we could share resources here. The iw package for
> example can also be switched easily.
Currently, Poky only has libnl2, and recipe name is libnl_2.0.bb, thus I added "libnl" as the wpa_supplicant's DEPENDS.
Something intersting that, though APIs are incompatible between libnl and libnl2, we didn't see build issues except this wpa_supplicant case when upgrading libnl from 1.1 to 2.0.
Could you list some OE packages which need libnl 1.1 as examples? We can check if we have included them in our current Poky build.
Thanks,
Dongxiao
>
> I fear I only have time to send patches to poky after the OE release
> in march.
> If you want to cherry-pick (if possible) patches that of course fine.
>
> regards
> Stefan Schmidt
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
^ permalink raw reply
* Re: [PATCH] Net, USB, Option, hso: Do not dereference NULL pointer
From: David Miller @ 2011-02-14 0:56 UTC (permalink / raw)
To: jj; +Cc: linux-kernel, linux-usb, netdev, gregkh, j.dumon, f.aben, d.barow,
ajb
In-Reply-To: <alpine.LNX.2.00.1102132206390.18930@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 13 Feb 2011 22:15:35 +0100 (CET)
> In drivers/net/usb/hso.c::hso_create_bulk_serial_device() we have this
> code:
> ...
> serial = kzalloc(sizeof(*serial), GFP_KERNEL);
> if (!serial)
> goto exit;
> ...
> exit:
> hso_free_tiomget(serial);
> ...
> hso_free_tiomget() directly dereferences its argument, which in the
> example above is a NULL pointer, ouch.
> I could just add a 'if (serial)' test at the 'exit' label, but since most
> freeing functions in the kernel accept NULL pointers (and it seems like
> this was also assumed here) I opted to instead change 'hso_free_tiomget()'
> so that it is safe to call it with a NULL argument. I also modified the
> function to get rid of a pointles conditional before the call to
> 'usb_free_urb()' since that function already tests for NULL itself -
> besides fixing the NULL deref this change also buys us a few bytes in
> size.
> Before:
> $ size drivers/net/usb/hso.o
> text data bss dec hex filename
> 32200 592 9960 42752 a700 drivers/net/usb/hso.o
> After:
> $ size drivers/net/usb/hso.o
> text data bss dec hex filename
> 32196 592 9960 42748 a6fc drivers/net/usb/hso.o
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied.
^ permalink raw reply
* Re: [PATCH] ATM, Solos PCI ADSL2+: Don't deref NULL pointer if net_ratelimit() and alloc_skb() interact badly.
From: David Miller @ 2011-02-14 0:55 UTC (permalink / raw)
To: jj; +Cc: linux-kernel, chas, linux-atm-general, netdev, nathan, dwmw2,
treker
In-Reply-To: <alpine.LNX.2.00.1102132142460.18930@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 13 Feb 2011 21:49:32 +0100 (CET)
> If alloc_skb() fails to allocate memory and returns NULL then we want to
> return -ENOMEM from drivers/atm/solos-pci.c::popen() regardless of the
> value of net_ratelimit(). The way the code is today, we may not return if
> net_ratelimit() returns 0, then we'll proceed to pass a NULL pointer to
> skb_put() which will blow up in our face.
> This patch ensures that we always return -ENOMEM on alloc_skb() failure
> and only let the dev_warn() be controlled by the value of net_ratelimit().
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied.
^ permalink raw reply
* Re: potential null pointer dereference in drivers/isdn/hisax/isdnl2.c
From: David Miller @ 2011-02-14 0:53 UTC (permalink / raw)
To: jj; +Cc: linux-kernel, netdev, tj, isdn
In-Reply-To: <alpine.LNX.2.00.1102032121180.15101@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Thu, 3 Feb 2011 21:27:56 +0100 (CET)
> In drivers/isdn/hisax/isdnl2.c:l2_pull_iqueue() we have this:
>
> ...
> skb = alloc_skb(oskb->len + i, GFP_ATOMIC);
> memcpy(skb_put(skb, i), header, i);
> ...
>
> If alloc_skb() fails and returns NULL then the second line will cause a
> NULL pointer dereference - skb_put() gives the pointer to
> skb_tail_pointer() which dereferences it.
>
> I'm not quite sure how this should be dealt with, so I'll just report it
> rather than submit a patch. Happy bug fixing :-)
Thanks Jesper, I'll fix this like so:
--------------------
hisax: Fix unchecked alloc_skb() return.
Jesper Juhl noticed that l2_pull_iqueue() does not
check to see if alloc_skb() fails.
Fix this by first trying to reallocate the headroom
if necessary, rather than later after we've made hard
to undo state changes.
Reported-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/isdn/hisax/isdnl2.c | 35 ++++++++++++++++++++---------------
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/isdn/hisax/isdnl2.c b/drivers/isdn/hisax/isdnl2.c
index 0858791..98ac835 100644
--- a/drivers/isdn/hisax/isdnl2.c
+++ b/drivers/isdn/hisax/isdnl2.c
@@ -1243,14 +1243,21 @@ l2_st7_tout_203(struct FsmInst *fi, int event, void *arg)
st->l2.rc = 0;
}
+static int l2_hdr_space_needed(struct Layer2 *l2)
+{
+ int len = test_bit(FLG_LAPD, &l2->flag) ? 2 : 1;
+
+ return len + (test_bit(FLG_LAPD, &l2->flag) ? 2 : 1);
+}
+
static void
l2_pull_iqueue(struct FsmInst *fi, int event, void *arg)
{
struct PStack *st = fi->userdata;
- struct sk_buff *skb, *oskb;
+ struct sk_buff *skb;
struct Layer2 *l2 = &st->l2;
u_char header[MAX_HEADER_LEN];
- int i;
+ int i, hdr_space_needed;
int unsigned p1;
u_long flags;
@@ -1261,6 +1268,16 @@ l2_pull_iqueue(struct FsmInst *fi, int event, void *arg)
if (!skb)
return;
+ hdr_space_needed = l2_hdr_space_needed(l2);
+ if (hdr_space_needed > skb_headroom(skb)) {
+ struct sk_buff *orig_skb = skb;
+
+ skb = skb_realloc_headroom(skb, hdr_space_needed);
+ if (!skb) {
+ dev_kfree_skb(orig_skb);
+ return;
+ }
+ }
spin_lock_irqsave(&l2->lock, flags);
if(test_bit(FLG_MOD128, &l2->flag))
p1 = (l2->vs - l2->va) % 128;
@@ -1285,19 +1302,7 @@ l2_pull_iqueue(struct FsmInst *fi, int event, void *arg)
l2->vs = (l2->vs + 1) % 8;
}
spin_unlock_irqrestore(&l2->lock, flags);
- p1 = skb->data - skb->head;
- if (p1 >= i)
- memcpy(skb_push(skb, i), header, i);
- else {
- printk(KERN_WARNING
- "isdl2 pull_iqueue skb header(%d/%d) too short\n", i, p1);
- oskb = skb;
- skb = alloc_skb(oskb->len + i, GFP_ATOMIC);
- memcpy(skb_put(skb, i), header, i);
- skb_copy_from_linear_data(oskb,
- skb_put(skb, oskb->len), oskb->len);
- dev_kfree_skb(oskb);
- }
+ memcpy(skb_push(skb, i), header, i);
st->l2.l2l1(st, PH_PULL | INDICATION, skb);
test_and_clear_bit(FLG_ACK_PEND, &st->l2.flag);
if (!test_and_set_bit(FLG_T200_RUN, &st->l2.flag)) {
--
1.7.4.1
^ permalink raw reply related
* Re: Problem with dependencies in packages
From: Graham Gower @ 2011-02-14 0:51 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTimuHfSAgfYK5V6zPAEG=MBCi_Am1_9rMq=M9xur@mail.gmail.com>
On 14 February 2011 10:59, Graham Gower <graham.gower@gmail.com> wrote:
> On 14 February 2011 09:20, Filip Zyzniewski <filip.zyzniewski@gmail.com> wrote:
>> Hi,
>>
>> I think I have found a problem with versioned dependencies (or I don't
>> unserstand something).
>>
>> I am trying to switch the jlime distribution from ipk to deb packages.
>> When debugging do_rootfs problems I stumbled upon this:
>>
>> The following packages have unmet dependencies:
>> libncursesw5: Depends: libtinfo5 (>= 5.7+20110115) but 5.7-r16 is to
>> be installed
>> E: Broken packages
>>
>> The Depends line in deb package control file comes from
>> classes/package_deb.bbclass:do_package_deb():
>>
>> rdepends = explode_deps(unicode(bb.data.getVar("RDEPENDS", localdata, 1) or ""))
>> [...]
>> ctrlfile.write(u"Depends: %s\n" % ", ".join(rdepends))
>>
>>
>> The dependency string comes from classes/package.bbclass:766:
>> dep = "%s (>= %s)" % (dep_pkg, ver_needed)
>>
>> ver_needed comes (in case of ncurses) from .ver files in the build
>> tree, generated by the same function a bit earlier using pkgver
>> variable set in lines 657-661:
>>
>> pkgver = bb.data.getVar('PKGV_' + pkg, d, True)
>> if not pkgver:
>> pkgver = bb.data.getVar('PV_' + pkg, d, True)
>> if not pkgver:
>> pkgver = ver
>>
>> and in ncurses_5.7.bb we have:
>>
>> PATCHDATE = "20110115"
>> PKGV = "${PV}+${PATCHDATE}"
>>
>>
>> Isn't this an incosistency that ncurses_5.7-r16 depends on
>> libtinfo5_5.7+20110115 ? Shouldn't it depend on libtinfo5_5.7-r16?
>
> Probably.
>
>> What's the reason for this situation? Does opkg somehow compare these
>> versions in another way causing the problem to be invisible?
>
> Opkg uses the same version comparison as dpkg. In fact, the
> verrevcmp() code in opkg was copied verbatim from dpkg. The ascii
> values of '+' and '-' are compared, with '+' being lower than '-'.
>
> # opkg compare-versions 5.7-r16 ">=" 5.7+20110115
> # echo $?
> 0
I think I may have just confused the issue with misinformation...
The hyphen is used as a delimiter between the version and the revision.
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
So the +date is part of the version, not the revision. Both opkg and
dpkg compare the versions and only if they are the same, the revisions
are compared (with the same verrevcmp function).
Furthermore, I assumed that a return code of 0 from opkg
compare-versions meant the comparison was true (like most success
return codes from applications). This is not the case.
# opkg compare-versions 1 ">=" 2 ; echo $?
0
# opkg compare-versions 2 ">=" 1 ; echo $?
1
> So, 5.7-r16 would be expected to satisfy the dependency in this case.
> I am unsure why the version comparison fails for you... maybe the dpkg
> comparison code has been changed since it was copied into ipkg?
>
In fact the dependency shouldn't be satisfied here. Opkg should fail
the same way as dpkg is failing.
-Graham
^ permalink raw reply
* Re: [PATCH 1/1, v7] cgroup/freezer: add per freezer duty ratio control
From: KAMEZAWA Hiroyuki @ 2011-02-14 0:44 UTC (permalink / raw)
To: Matt Helsley
Cc: jacob.jun.pan, LKML, Kirill A. Shutemov, Arjan van de Ven,
container cgroup, Li Zefan, Paul Menage, akpm, rdunlap,
Cedric Le Goater
In-Reply-To: <20110212232907.GN16432@count0.beaverton.ibm.com>
On Sat, 12 Feb 2011 15:29:07 -0800
Matt Helsley <matthltc@us.ibm.com> wrote:
> On Fri, Feb 11, 2011 at 11:10:44AM -0800, jacob.jun.pan@linux.intel.com wrote:
> > From: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >
> > Freezer subsystem is used to manage batch jobs which can start
> > stop at the same time. However, sometime it is desirable to let
> > the kernel manage the freezer state automatically with a given
> > duty ratio.
> > For example, if we want to reduce the time that backgroup apps
> > are allowed to run we can put them into a freezer subsystem and
> > set the kernel to turn them THAWED/FROZEN at given duty ratio.
> >
> > This patch introduces two file nodes under cgroup
> > freezer.duty_ratio_pct and freezer.period_sec
>
> Again: I don't think this is the right approach in the long term.
> It would be better not to add this interface and instead enable the
> cpu cgroup subsystem for non-rt tasks using a similar duty ratio
> concept..
>
> Nevertheless, I've added some feedback on the code for you here :).
>
AFAIK, there was a work for bandwidth control in CFS.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-10/msg04335.html
I tested this and worked fine. This schduler approach seems better for
my purpose to limit bandwidth of apprications rather than freezer.
BTW, isn't period_sec too large ?
Thanks,
-Kame
^ permalink raw reply
* [PATCH] Btrfs: check return value of alloc_extent_map()
From: Tsutomu Itoh @ 2011-02-14 0:45 UTC (permalink / raw)
To: linux-btrfs; +Cc: chris.mason
I add the check on the return value of alloc_extent_map() to several places.
In addition, alloc_extent_map() returns only the address or NULL.
Therefore, check by IS_ERR() is unnecessary. So, I remove IS_ERR() checking.
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/extent_map.c | 4 ++--
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 3 +++
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 565e22d..a7aaa10 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6584,7 +6584,7 @@ static noinline int relocate_data_extent(struct inode *reloc_inode,
u64 end = start + extent_key->offset - 1;
em = alloc_extent_map(GFP_NOFS);
- BUG_ON(!em || IS_ERR(em));
+ BUG_ON(!em);
em->start = start;
em->len = extent_key->offset;
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index b0e1fce..2b6c12e 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -51,8 +51,8 @@ struct extent_map *alloc_extent_map(gfp_t mask)
{
struct extent_map *em;
em = kmem_cache_alloc(extent_map_cache, mask);
- if (!em || IS_ERR(em))
- return em;
+ if (!em)
+ return NULL;
em->in_tree = 0;
em->flags = 0;
em->compress_type = BTRFS_COMPRESS_NONE;
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index b0ff34b..65338a1 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -185,6 +185,7 @@ int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end,
split = alloc_extent_map(GFP_NOFS);
if (!split2)
split2 = alloc_extent_map(GFP_NOFS);
+ BUG_ON(!split || !split2);
write_lock(&em_tree->lock);
em = lookup_extent_mapping(em_tree, start, len);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c9bc0af..8d392ed 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -644,6 +644,7 @@ retry:
async_extent->ram_size - 1, 0);
em = alloc_extent_map(GFP_NOFS);
+ BUG_ON(!em);
em->start = async_extent->start;
em->len = async_extent->ram_size;
em->orig_start = em->start;
@@ -820,6 +821,7 @@ static noinline int cow_file_range(struct inode *inode,
BUG_ON(ret);
em = alloc_extent_map(GFP_NOFS);
+ BUG_ON(!em);
em->start = start;
em->orig_start = em->start;
ram_size = ins.offset;
@@ -1169,6 +1171,7 @@ out_check:
struct extent_map_tree *em_tree;
em_tree = &BTRFS_I(inode)->extent_tree;
em = alloc_extent_map(GFP_NOFS);
+ BUG_ON(!em);
em->start = cur_offset;
em->orig_start = em->start;
em->len = num_bytes;
^ permalink raw reply related
* Re: The Ceph wiki?
From: Daniel Friesen @ 2011-02-14 0:44 UTC (permalink / raw)
To: ceph-devel
In-Reply-To: <Pine.LNX.4.64.1102131028450.27567@cobra.newdream.net>
On 11-02-13 10:30 AM, Sage Weil wrote:
> On Sun, 13 Feb 2011, Daniel Friesen wrote:
>> I noticed the Ceph wiki is fairly out of date, and wrought with the usual spam
>> (well, having .pdf enabled entitles a type of spam I haven't seen before).
>> Which felt a little concerning, since the wiki appears to be the primary
>> source of documentation, and Ceph looks like an active project with a lot of
>> potential.
>>
>> Could the Ceph group use my help maintaining the wiki?
> Absolutely! Let me know what (if any) privs you need to work with it, or
> what ought to be fixed up with the configuration.
>
> sage
- Upgrading and installation of various anti-spam extensions still need
commands to be run, so wherever it is I'll need shell access...
-- and a mysql account with allprivs on the database the wiki is on.
-- I prefer to maintain MW by checking it out from svn anyways (the
REL1_## branches).
- I'll probably also setup the usual cron job I use (job queue in cron,
sitemap generation, ...) so I'll need to be able to create one of those.
- I'm undecided on whether I should setup a 404 image handler since
there aren't many images being used (a handler speeds up page loads by
not making them dependent on the completion of thumbnail generation).
Whether you want me in the servers, or want me to host it on one of mine
is up to you. I'm already hosting the CommonJS wiki and website.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
^ permalink raw reply
* Re: Siano SMS1140 DVB Receiver on Debian 5.0 (Lenny)
From: Mauro Carvalho Chehab @ 2011-02-14 0:43 UTC (permalink / raw)
To: jamenson; +Cc: linux-media
In-Reply-To: <4d554a2295c4b_de09815034196@a2-winter4.tmail>
Em 11-02-2011 12:39, jamenson@bol.com.br escreveu:
> Hi everyone.
>
> I'm sorry if my question is a newbie question. I have a DVB receiver (Siano SMS1140).
<snip/>
> using settings for BRAZIL
I'm assuming that what you're trying to do is to use it for ISDB-T, right?
You may find some useful info (in Portuguese) at:
http://br-linux.org/2010/tv-digital-brasileira-no-linux-mais-drivers-experimentais-disponiveis/
The tree indicated there is outdated (it was a test tree I've created some time ago). The latest
drivers are available at the main devel tree. You may use the media_build tree to download and
compile with your kernel version:
http://git.linuxtv.org/media_build.git
Also, AFAIK, vdr doesn't work with ISDB-T. The only application that I know for sure that works
with h.264/aac isdb-t decoding is vlc.
Cheers,
Mauro.
^ permalink raw reply
* Re: [PATCH 1/1, v7] cgroup/freezer: add per freezer duty ratio control
From: KAMEZAWA Hiroyuki @ 2011-02-14 0:44 UTC (permalink / raw)
To: Matt Helsley
Cc: Cedric Le Goater, jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA,
container cgroup, LKML, rdunlap-/UHa2rfvQTnk1uMJSBkQmQ,
Paul Menage, Arjan van de Ven,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20110212232907.GN16432-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
On Sat, 12 Feb 2011 15:29:07 -0800
Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, Feb 11, 2011 at 11:10:44AM -0800, jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org wrote:
> > From: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >
> > Freezer subsystem is used to manage batch jobs which can start
> > stop at the same time. However, sometime it is desirable to let
> > the kernel manage the freezer state automatically with a given
> > duty ratio.
> > For example, if we want to reduce the time that backgroup apps
> > are allowed to run we can put them into a freezer subsystem and
> > set the kernel to turn them THAWED/FROZEN at given duty ratio.
> >
> > This patch introduces two file nodes under cgroup
> > freezer.duty_ratio_pct and freezer.period_sec
>
> Again: I don't think this is the right approach in the long term.
> It would be better not to add this interface and instead enable the
> cpu cgroup subsystem for non-rt tasks using a similar duty ratio
> concept..
>
> Nevertheless, I've added some feedback on the code for you here :).
>
AFAIK, there was a work for bandwidth control in CFS.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-10/msg04335.html
I tested this and worked fine. This schduler approach seems better for
my purpose to limit bandwidth of apprications rather than freezer.
BTW, isn't period_sec too large ?
Thanks,
-Kame
^ permalink raw reply
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
From: Mark Zimmerman @ 2011-02-14 0:37 UTC (permalink / raw)
To: Andy Walls; +Cc: Devin Heitmueller, linux-media
In-Reply-To: <1297632410.2401.6.camel@localhost>
On Sun, Feb 13, 2011 at 04:26:50PM -0500, Andy Walls wrote:
> On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote:
> > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote:
> > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote:
> > > > Clearly my previous bisection went astray; I think I have a more
> > > > sensible result this time.
> > > >
> > > > qpc$ git bisect good
> > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
> > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be
> > > > Author: Jean Delvare <khali@linux-fr.org>
> > > > Date: ? Sun Jul 18 16:52:05 2010 -0300
> > > >
> > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions
> > > >
> > > > ? ?Don't just check for nacks on zero-length transactions. Check on
> > > > ? ?other transactions too.
> > >
> > > This could be a combination of the xc5000 doing clock stretching and
> > > the cx23885 i2c master not properly implementing clock stretch. In
> > > the past I've seen i2c masters broken in their handling of clock
> > > stretching where they treat it as a NAK.
> > >
> > > The xc5000 being one of the few devices that actually does i2c clock
> > > stretching often exposes cases where it is improperly implemented in
> > > the i2c master driver (I've had to fix this with several bridges).
> > >
> >
> > Thanks for your insight. I am looking at cx23885-i2c.c and there is no
> > clock stretching logic in i2c_slave_did_ack(). Would this be the
> > right place for it to be? Can you point me to an example of another
> > driver that does it correctly? I really don't know what I am doing...
>
>
> Mark,
>
> You don't have much hope of getting that right without the CX23885
> datasheet.
>
> Let's just get the bad commit reverted and into 2.6.38, and fix what
> used to work for you. Doing a git bisect is enough work for anyone.
>
> I'll do a patch to revert the commit and ask it to be pulled for
> 2.6.38-rc-whatever. I'll be sure to add a
>
> Bisected-by: Mark Zimmerman <markzimm@frii.com>
>
> tag to the patch. (The Linux Kernel devs understand the work involved
> to do a bisection.)
>
>
> Later, if I can work up a patch to deal with clock stretching properly,
> I may ask you to test.
>
Thanks, that would be great. Meanwhile, I have built a 2.6.37 with the
offending commit removed:
git bisect reset
git checkout v2.6.37
git revert 44835f197bf1e3f57464f23dfb239fef06cf89be
and it seems to be working fine using both tuners:
xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
xc5000: firmware read 12401 bytes.
xc5000: firmware uploading...
xc5000: firmware upload complete...
xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
xc5000: firmware read 12401 bytes.
xc5000: firmware uploading...
xc5000: firmware upload complete...
Thanks again
-- Mark
^ permalink raw reply
* klist: Fix object alignment on 64-bit.
From: David Miller @ 2011-02-14 0:37 UTC (permalink / raw)
To: torvalds; +Cc: jesper.nilsson, linux-kernel
Commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b ("klist.c: bit 0 in
pointer can't be used as flag") intended to make sure that all klist
objects were at least pointer size aligned, but used the constant "4"
which only works on 32-bit.
Use "sizeof(void *)" which is correct in all cases.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/include/linux/klist.h b/include/linux/klist.h
index e91a4e5..a370ce5 100644
--- a/include/linux/klist.h
+++ b/include/linux/klist.h
@@ -22,7 +22,7 @@ struct klist {
struct list_head k_list;
void (*get)(struct klist_node *);
void (*put)(struct klist_node *);
-} __attribute__ ((aligned (4)));
+} __attribute__ ((aligned (sizeof(void *))));
#define KLIST_INIT(_name, _get, _put) \
{ .k_lock = __SPIN_LOCK_UNLOCKED(_name.k_lock), \
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Regression - Xorg start failed
From: Chris Wright @ 2011-02-14 0:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Dave Young, linux-kernel, David Airlie, dri-devel,
Chris Wright, James Morris
In-Reply-To: <AANLkTimxCMgdfht7rrg8QiCppb=D7fvR92eeiewdqCpH@mail.gmail.com>
* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Sat, Feb 12, 2011 at 11:53 PM, Dave Airlie <airlied@gmail.com> wrote:
> > Probably should revert first, then work out what is crapping out libpciaccess.
>
> Yeah, I'll revert. The patch is one of those "obviously a good idea,
> but in practice it's not something we can change now".
Turns out I'm just a bona fide idiot.
I was not testing the right kernel _and_ didn't get the logic right.
sorry for the screw up,
-chris
---
Subject: [PATCH] pci: use security_capable correctly during config space read
Commit 47970b1 ("pci: use security_capable() when checking capablities
during config space read") is just plain broken. The normal capable()
interface returns true on success, but the LSM interface returns 0 on
success.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
I've tested this quickly (lspci behaviour is as expected).
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index f7771f3..ea25e5b 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -369,7 +369,7 @@ pci_read_config(struct file *filp, struct kobject *kobj,
u8 *data = (u8*) buf;
/* Several chips lock up trying to read undefined config space */
- if (security_capable(filp->f_cred, CAP_SYS_ADMIN)) {
+ if (security_capable(filp->f_cred, CAP_SYS_ADMIN) == 0) {
size = dev->cfg_size;
} else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
size = 128;
^ permalink raw reply related
* Re: [PATCH 1/3] libxfs: reintroduce old xfs_repair radix-tree code
From: Dave Chinner @ 2011-02-14 0:36 UTC (permalink / raw)
To: Alex Elder; +Cc: xfs
In-Reply-To: <1297274713.2513.27.camel@doink>
On Wed, Feb 09, 2011 at 12:05:13PM -0600, Alex Elder wrote:
> On Mon, 2011-01-10 at 19:44 +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > The current kernel code uses radix trees more widely than the
> > previous code, so for the next sync we need radix tree support in
> > libxfs. Pull the old radix tree code out the xfs_repair git history
> > and move it into libxfs to simplify the kernel code sync.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
>
> OK, I actually reviewed this code, even though it had
> already been present in the source tree prior to commit:
> 379397bf9... ("repair: use a btree instead of a radix tree
> for the prefetch queue").
>
> And I have some suggestions, and I have at least one
> thing that I think is a bug.
>
> I also notice that this code apparently formed the
> basis of the kernel's implementation. That's good.
> It's probably worth reviewing the kernel version's
> history to see if there are any bug fixes that ought
> to be brought back into this code (and vice-versa).
>
>
> All that being said, I think the right thing to do
> is to include this change as-is as a commit. It
> includes both "radix-tree.c" and "radix-tree.h" as
> identical copies of what was removed (though each
> now resides in a different directory from before),
> thereby preserving the provenance of the code.
>
> Then, after it's committed, I can offer my suggested
> changes, or even just implement and propose them
> myself.
>
> So unless you disagree with this approach I think
> it's fine to commit it as you originally posted it.
I think that is a fine way to proceed ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 0/5] iwlwifi: Auto-tune tx queue size to maintain latency under load
From: Julian Calaby @ 2011-02-14 0:32 UTC (permalink / raw)
To: Nathaniel J. Smith; +Cc: linville, linux-wireless, wey-yi.w.guy, ilw
In-Reply-To: <1297619803-2832-1-git-send-email-njs@pobox.com>
On Mon, Feb 14, 2011 at 04:56, Nathaniel J. Smith <njs@pobox.com> wrote:
> I have an iwl3945 in my laptop, and find that whenever I saturate the
> outgoing connection -- which happens daily when my rsync backup kicks
> in -- then latency becomes astronomical (what Jim Gettys calls
> "bufferbloat"). I've measured 12-13 second ping times to my router. As
> you can imagine, this makes web browsing or interactive SSH somewhat
> uncomfortable.
For those who aren't aware of this, more info:
http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/
Re-(re-)stating the issue in question: When a network link is
congested, packets are being buffered for a "long" time in an attempt
to not drop any traffic; despite almost all protocols being either
built on TCP or designed to deal with packet loss. This causes latency
issues as the sender is not receiving any indication that the network
is congested and hence continuing to send as fast as it can, filling
these buffers and causing high latencies as they are emptied out over
the congested link.
The short term solution (but not an overall solution by any means) is
to reduce these buffers so that packets are dropped when links are
congested.
> This patch series teaches the driver to measure the average rate of
> packet transmission for each tx queue, and adjusts the queue size
> dynamically in an attempt to achieve ~2 ms of added latency.
IMHO, I'm not sure that this is the best method of implementing this
solution: most wireless (and ethernet) devices have some form of
buffer for the same reason, so implementing a solution for iwlwifi is
not an overall solution - we need some method of doing this for *all*
network devices, not just iwlwifi.
That said, your reasoning for the queue management simplification
seems sound - but as I don't know the iwlwifi code so I can't really
comment on it any further than that.
Finally, your numbers are damn impressive, and this is the first
attempt that I'm aware of to solve this problem.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: Problem with dependencies in packages
From: Graham Gower @ 2011-02-14 0:29 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTikP8CNgvex==mnJY8McTouY0n-QzcUQjaFZRV8X@mail.gmail.com>
On 14 February 2011 09:20, Filip Zyzniewski <filip.zyzniewski@gmail.com> wrote:
> Hi,
>
> I think I have found a problem with versioned dependencies (or I don't
> unserstand something).
>
> I am trying to switch the jlime distribution from ipk to deb packages.
> When debugging do_rootfs problems I stumbled upon this:
>
> The following packages have unmet dependencies:
> libncursesw5: Depends: libtinfo5 (>= 5.7+20110115) but 5.7-r16 is to
> be installed
> E: Broken packages
>
> The Depends line in deb package control file comes from
> classes/package_deb.bbclass:do_package_deb():
>
> rdepends = explode_deps(unicode(bb.data.getVar("RDEPENDS", localdata, 1) or ""))
> [...]
> ctrlfile.write(u"Depends: %s\n" % ", ".join(rdepends))
>
>
> The dependency string comes from classes/package.bbclass:766:
> dep = "%s (>= %s)" % (dep_pkg, ver_needed)
>
> ver_needed comes (in case of ncurses) from .ver files in the build
> tree, generated by the same function a bit earlier using pkgver
> variable set in lines 657-661:
>
> pkgver = bb.data.getVar('PKGV_' + pkg, d, True)
> if not pkgver:
> pkgver = bb.data.getVar('PV_' + pkg, d, True)
> if not pkgver:
> pkgver = ver
>
> and in ncurses_5.7.bb we have:
>
> PATCHDATE = "20110115"
> PKGV = "${PV}+${PATCHDATE}"
>
>
> Isn't this an incosistency that ncurses_5.7-r16 depends on
> libtinfo5_5.7+20110115 ? Shouldn't it depend on libtinfo5_5.7-r16?
Probably.
> What's the reason for this situation? Does opkg somehow compare these
> versions in another way causing the problem to be invisible?
Opkg uses the same version comparison as dpkg. In fact, the
verrevcmp() code in opkg was copied verbatim from dpkg. The ascii
values of '+' and '-' are compared, with '+' being lower than '-'.
# opkg compare-versions 5.7-r16 ">=" 5.7+20110115
# echo $?
0
So, 5.7-r16 would be expected to satisfy the dependency in this case.
I am unsure why the version comparison fails for you... maybe the dpkg
comparison code has been changed since it was copied into ipkg?
> bye,
> Filip Zyzniewski
-Graham
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.